| Age | Commit message (Collapse) | Author |
|---|
|
Well, at least not to crash.
|
|
Currently, our API uses static inlines for fz_lock and
fz_unlock, the definitions for which depend on whether
we build NDEBUG or not. This isn't ideal as it causes
problems when people link a release binary with a debug
lib (or vice versa).
We really want to continue to use static inlines for the
locking functions as used from MuPDF, as we hit them
hard in the keep/drop functions.
We therefore remove fz_lock/fz_unlock from the public API
entirely. Accordingly, we move the fz_lock/fz_unlock
static inlines into fitz-imp.h (an internal header),
together with the fz_keep_.../fz_drop_... functions.
We then have public fz_lock/fz_unlock functions for any
external callers to use that are free of compilications.
At the same time, to avoid another indirection, we change
from holding the locking functions as a pointer to a
struct to a struct itself.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
|
|
When mapping spots down to process colors, don't try to map
disabled spots.
|
|
|
|
As seen with ../tests_private/comparefiles/Bug693541.pdf
This file has an RGB isolated group, within which it renders a
spot only shading. We therefore create the RGB+S+A pixmap, and
set it to all zeros. The shading is drawn to a new S+A pixmap.
The problem comes when the code writes the S+A pixmap to the
RGB+S+A one.
When we set the alpha values to be non zero in an additive space
we need to reset the process components to be full (scaled by
alpha).
|
|
|
|
The 'producing spots' case is poorly tested, but I believe we
should be keeping the spot information internally, rather than
NULLing it out.
|
|
This is a first cut to get us to demo-ability. There will
likely be a few changes as we do a bit more testing with different
scenarios with Gray, RGB, CMYK combos of destination, proof and
output intent ICC profiles.
|
|
The proof conversion should only be done after we
have done all our drawing in the separations
group. Fixes issue in page 7 of Altona test.
|
|
Special care is required when the DeviceN color space has
cyan, magenta, yellow or black.
For example, even if we support separations in the destination, if
the color space has CMY or K as one of its colorants and we are
drawing to an RGB or Gray pixmap we will want to do the tint transform.
Also if the pixmap has no seps memember present, we support the
separations if the destination is CMYK and the DeviceN colorspace
has no "Spot" (non-CMYK) colorants.
|
|
|
|
|
|
Incorporates fixes from Michael.
Rather than specifically giving it rgb and cmyk values,
separations now include the colorspace. Conversions can
then be done into ANY colorspace we need.
Note, that we maintain the old way of working for the
gproof device.
Also, fix pdf_page_separations to correctly find all separations.
This involves recursively looking through colorspaces, forms
and shadings for colorspaces therein, making sure we don't run
into any circular references.
We do 2 passes, so that we can pick up as many colorants as Separations
as possible. On the second pass we pick up any colorants we missed in
terms of DeviceN spaces. The purpose of this is to try to ensure that
we get as many tint transforms as single input functions as we can.
This may not be important in the grand scheme of things, but seems
neater.
|
|
If draw device is passed a pixmap with disabled separations, it
may have to push an extra group at the top to allow for the
actual rendering to properly happen in cmyk+spots, and then get
folded down at the end.
This pushing cannot happen at create time, due to it being
dependent on the defualt_cs settings. Accordingly, we push it
(just once) on the first drawing operation.
This means we need to be able to convert from "colorspace + set
of spots" to "different colorspace + different set of spots".
This in turn means we need to be able to drive lcms slightly
differently (to tell it whether to copy the spots unchanged
or not), so we have to amend the CMS interface code a bit for
that.
Currently we lack plotters to properly cope with plotting
images and shades with spots, so this will give a warning and
do nothing. To be filled in in future commits.
Ensure fz_get_icc_link accepts NULL to mean default color params.
Incorporates fixes from Michel Vrhel:
With transparency groups we can have RGB + spot pixmaps. When
drawing into those we need a mixture of colorant polarity. Ensure
that fz_convert_separation_colors takes account of this.
Fix C1 of Altona_Technical_1v1_x3.pdf (allow for output intent in
fz_clone_pixmap_area_with_different_seps).
|
|
Update separations interface further to cope with whether spots
should be rendered separately, or as composite colors.
|
|
Specifically this is aimed so we can efficiently get separation
details for PDF files (which may require a lengthy search process).
|
|
Code MUST pass a non-null context to all functions.
Checking ctx for null and failing silently is no more useful
than segfaulting.
fz_keep_imp and fz_drop_imp handle NULL pointers safely, so
the NULL checks for this can also be dropped at the same time.
|
|
|
|
Include code to free the list of separation names.
|
|
Simple set of functions for managing sets of separations. Separations
have names, equivalent rgb/cmyk colors, and can be enabled/disabled.
|
