| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
fast_rgb_to_cmyk had || instead of && so always triggered incorrectly.
Only throw, no need to both assert and throw.
|
|
If you want accurate CMYK, don't build with FZ_ENABLE_ICC=0.
|
|
|
|
|
|
|
|
|
|
|
|
The exception is still thrown, however. This just
ensures that CMM is not left in an unknown state.
|
|
By setting ctx->cmm_instance == NULL we actively made sure that
fz_cmm_fin_profile() would never call ->fin_profile() to actually
clean up the ICC profiles.
This could be triggered by doing mutool draw -N even without a
file name, triggering a memory leak.
|
|
|
|
|
|
|
|
|
|
|
|
Previously this would result in trying to dereference a NULL pointer.
Thanks to oss-fuzz for reporting.
|
|
|
|
Several things irk me about passing values as const pointers:
* They can be NULL, which is not a valid value.
* They require explicit temporary variables for storage.
* They don't compose easily in a legible manner, requiring
weird pointer passing semantics where the variable being assigned
is hidden as an argument in the innermost function call.
* We can't change the value through the pointer, requiring yet more
local variables to hold copies of the input value.
In the device interface where we pass a matrix to a function, we often
find ourselves making a local copy of the matrix so we can concatenate
other transforms to it. This copying is a lot of unnecessary busywork
that I hope to eventually avoid by laying the groundwork with this
commit.
This is a rather large API change, so I apologize for the inconvenience,
but I hope the end result and gain in legibility will be worth the pain.
|
|
|
|
|
|
|
|
I did not foresee the case where a transparency groups color
space could be a Cal color space. I had always thought of them
as only be source color spaces not destination color spaces.
This commit makes sure that we have the equivalent ICC profile
when the destination is a Cal space.
|
|
Without this change future calls to fz_fin_cached_color_converter()
will try to dereference the already freed pointer.
|
|
|
|
|
|
If we attempt to make an icc colorspace in a NO_ICC build, throw
an exception. This stops us ending up with 'UNKNOWN' colorspaces
in the system.
|
|
When converting from a source space to a destination space with
spots for our "overprint" group push, we were hitting problems
in our use of the pixmap converters.
Pixmap converters with copy_spots set can assume that the source
and destination spots are the same - when copy spots is NOT set,
we cannot assume this. This was leading us to have uninitialised
group backgrounds.
I believe we were only seeing this with pgm because of the device
k to cmyk as K only special case.
Also fix an error in the fast_gray_to_cmyk routine that failed to
account for the change from subtractive to additive.
|
|
|
|
|
|
This is needed so that we can have bgr formatting with
something other than the default sRGB
|
|
|
|
If the OutputIntent is set, we used to set Device{Gray,RGB,CMYK}
(as appopriate) to match it. Don't do this if it's already
been set to something other than our defaults.
|
|
|
|
|
|
|
|
Adjust the decode array to allow for the fact that the default
decode is done by the ICC code.
|
|
When source color is DeviceGray, and the destination color CMYK
we should map the gray values to K.
See note in Section 6.3 of PDF spec.
|
|
|
|
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.
|
|
This file has a type 3 font in it. It first uses
a 'd1' glyph, that uses a pattern. Accordingly, we
we render that pattern to a mask tile and store that
tile. Then it uses a 'd0' glyph, which uses the same
pattern. The cache is checked, and we erroneously pick
up the cached tile to reuse it - but this is not a
colored rendering, so we assert on plotting.
The fix is to ensure that the required colorspaces
match. This requires us to add the colorspace to the
tile key. Unfortunately, this means that colorspaces
have to become key_storable, so the patch is slightly
larger than would otherwise be the case.
|
|
Ensure that if we ask for a color converter for a NULL
colorspace, that we treat it as devicegray. This copes with
the mask cases.
|
|
|
|
|
|
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).
|
|
|
|
fz_colorspace.name is an array, not a pointer, so will never be NULL.
|
|
|
|
|
