| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Also save link coordinates in outline nodes.
|
|
Also apply an inverse gamma correction curve.
|
|
|
|
Use fz_xml_is_tag instead of fz_xml_tag && !strcmp idiom.
|
|
|
|
xps_load_links_in_glyphs did not cope with font loading failures.
|
|
|
|
|
|
|
|
Proper blending of spots is dependent upon the blending
color space as well as the blend mode. In particular
when the blend mode is non-separable or non-white preserving
normal blending should be used for the spot colorants.
Incorporates various fixes and optimisations squashed back
to this one commit for clarity. Some of these fixes/optimisations
are due to Michael Vrhel.
In particular we move to handling non-isolated groups in the same
way as gs.
|
|
|
|
Incorporates fixes from Michael: When dealing with spot colors, if the
destination space is pure CMYK and we have unsupported spots we can
do a weighted addition of the spot CMYK colorant like Adobe does
in the PSD image format. If the destination space is RGB we need
to do a traditional color mapping of each pixel.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Linux specific and depends on the inotify-tools package. Will watch
source and header files and rebuild mupdf when they are modified.
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
