| Age | Commit message (Collapse) | Author |
|---|
|
If a colorant is not an explicit separation, then it will be
mapped down to process colorants. These cannot be protected
from overprint.
Incorporates a fix for a problem with shades seen on page 8 of.
Altona_Technical_v20_x4. This shows a problem where we were failing
to correctly overprint a grey gradient with a spot color one.
The overprint setup code was checking for 'Orange' being one of
the process colours, and not finding it. Consequently it was deciding
that Orange would have to be mapped to a process color, and so the
process colors could not be protected from overprint.
The code should have spotted that 'Orange' was one of the spot
colors. With this added, it works correctly.
|
|
Adjust the decode array to allow for the fact that the default
decode is done by the ICC code.
|
|
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.
|
|
|
|
|
|
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.
|
|
Introduce an fz_overprint bitmap (currently just a uint32_t,
but it'll grow to be an array of them if FZ_MAX_COLOR is
increased). Pointers to this are passed into all our
painting routines.
NULL means "Do what you've always done before, with no overprint".
non NULL, means that every set bit means "don't ever alter this
component".
We therefore set the overprint bitmap up according to the input
color/colorspace/colorparams before calling each routine.
|
|
|
|
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 gives us a friendlier interface to zlib.
Simplifies PNG output and PCLM output code.
|
|
This is to avoid conflict with the next commit.
|
|
Both bandwriter and document_writer interfaces cope with multi
page docs.
Update mudraw to output pclm format too.
Incorporates fixes from Tor.
|
|
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.
|
|
Make sure any changes to the page tree are always reflected immediately.
The rev_page_map lookup cache exists when we load the outlines in order
to resolve links faster, so we don't need to worry about that one.
The linear_page_refs stuff is more troublesome, so don't mix editing a
PDF with progressive loading!
|
|
|
|
Avoid double freeing the device colorspaces.
|
|
|
|
HTML doesn't respect the DPI setting, so SVG images end up too big.
|
|
|
|
|
|
|
|
The code only worked for string literals, not garbage collected or
short strings.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This really should have been part of commit
0ef7cb983c4325156e08525381542ae3ada04720.
|
|
|
|
|
|
|
|
|
|
The change in 2707fa9e8e6d17d794330e719dec1b08161fb045
in build_filter_chain() allows for the variable chain
to reside in a register, which means that the bug is
likely to only be visible if built under optimization.
First the chain variable is transferred to chain2, then
set to NULL, then when an exception occurs in build_filter()
the filter chain will be freed by build_filter(). Next
the expectation is that execution proceeds to fz_catch()
where fz_drop_stream() would be called with chain == NULL.
However due to the chain variable residing in a register,
its value is not NULL as expected, but was reset to its
original value upon the exception (since they use setjmp()),
hence fz_drop_stream() is called with a non-NULL value.
Marking the chain variable with fz_var() prevents the
compiler from allowing the chain variable to reside in
a register and hence its value will remain NULL and
never be reset.
|
|
Sometimes ASAN issues only occur if optimization is
enabled. This build target allows for testing under
these conditions.
|
|
|
|
|
|
Sebastian points out that at various points we assign state
only to overwrite it without using it later on. Harmless, but
fixed here for neatness. Thanks.
|
|
|
|
|
|
|
|
|
|
Previously, in case of error in fz_jpg_mem_init(),
jpeg_finish_decompress()/jpeg_destroy_decompress()
would be called before jpeg_create_decompress() had
initlized all state. This sometimes led to segfaults
or accessing uninitialized data.
|
|
|
|
|
