| Age | Commit message (Collapse) | Author |
|---|
|
Using #ifdef FZ_ENABLE_ means we build code in, even if we have
defined FZ_ENABLE_WHATEVER to be 0 (as we do in config.h).
|
|
|
|
When fz_draw_clip_image_mask() calls fz_get_pixmap_from_image()
may throw an exception, in this case beacuse a predicted image
has an unsupported number of components (1, 2, 4, 8 and 16 are
supported, but 6 is not). When this happens the recently pushed
stack element is never popped, which later trips an assert() in
fz_draw_end_group() at a later stage.
By moving the call to fz_get_pixmap_from_image() inside fz_try
the stack will be popped, thus avoiding triggering the assert().
This also requires the pixmap variable to be fz_var()ed because
it changes inside the fz_try-block.
|
|
|
|
Create a matrix that transforms a page with resolution and rotation,
and grid fits the resulting bounding box.
|
|
|
|
|
|
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.
|
|
|
|
Without this fix the stack may be resized and relocated and
then the scissor might point to stale memory.
|
|
aa.text_bits should be 0 when using the 'any' or 'center' rasterizers.
|
|
|
|
Previously the call to fz_convert_pixmap() threw causing a destination
pixmap leak. This illustrated a bigger issue with the error handling
so now all types of pixmaps are dropped and care is taken to also end
the knockout group, should there be any.
|
|
|
|
|
|
Don't attempt to rely on alpha, as it is incompatible with the way
we clip through the mask at the end.
|
|
Also do not do the extra group push if the destination pixmap
is in the proper color space and has all the required sep support.
|
|
This way the MuPDF library itself only uses fz_snprintf for
consistent formatting.
|
|
Michael has found a crash when scrolling quickly through pages
with gsview. 2 Threads are redrawing at the same time from a
display list. The problem comes when both threads happen to be
trying to draw the same tile from the cache at the same time.
The current code alters the ->{x,y} values of the pixmap from
the cache as it tiles. If 2 threads are using the same tile
at the same time, this causes a race condition which can upset
the clipping calculations and we can access out of range.
The solution is to make a new 'wrapper' fz_pixmap around the
same data, and to alter the x/y values there instead.
We therefore introduce a (hopefully generally useful) function
fz_new_pixmap_from_pixmap, and use that.
|
|
If cmyk color spaces don't match, we should still honor overprint
just not overprint mode.
|
|
It seems we need to treat group alpha differently for isolated and
non-isolated groups.
|
|
For Ghent_V3.0/030_Gray_K_black_OP_x1a.pdf and
Ghent_V3.0/110_defaultcolourspace_x3.pdf.
|
|
Testing tests/Ghent_V3.0/132_ICCbasedOverPrint.pdf shows that
we were incorrectly allowing performing the overprint magic
in the case where we were rendering to a CMYK pixmap in a
different CMYK space. This is not allowed.
|
|
Fix Ghent_V3.0/070_OutputIntent_ISOCoated-v1_x3.pdf.
Partially Fix Ghent_V5.0/GWG190_DeviceN_Overprint_Black_X1a.pdf
Cope with 'All' and 'None' colorants. Files with 'All' and 'None'
colorants can still count as being "entirely CMYK" for the purposes
of color conversion.
There is a still an overprint problem with the 3rd swatch of
Ghent_V5.0/GWG190_DeviceN_Overprint_Black_X1a.pdf.
|
|
Running Ghent_V5.0/GWG010_CMYK_OP_x3.pdf to PNG produces
'X' marks, where Acrobat does not. This is expected if
overprint similation is turned off, but not if it is
enabled.
The file does not define a colorspace for the initial page,
uses no transparency, and has no spots defined. Accordingly,
when we clone the page fz_separation object, we end up with
no object at all. The draw device therefore doesn't even
attempt to do overprint simulation.
We fix this by ensuring that we always have a non-NULL
separation object. Possibly we should make fz_page_separations
return a non-NULL, but empty object?
Even with this change, running to PNG still does not give the
required rendering. This is because PNGs use RGB, rather than
CMYK, and overprint is disabled for non-subtractive spaces.
We therefore adjust the code in push_group_for_separations
that decides whether it can avoid pushing an extra group.
If the basic pixmap is RGB, then we never skip the extra
group.
|
|
The "blend back" at the end of the inner knockout groups was
attempting to reuse the existing blending code. This was going
wrong for all sorts of reasons (not least the uncomposition
phase) for knockout groups containing alpha, such as found on
page 7 of Altona_Technical_v20_x4.pdf.
Use a dedicated routine. This is much simpler as it doesn't have
to cope with blend modes etc.
|
|
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.
|
|
|
|
When pushing a transparency group, MuPDF used to always create a shape
plane if there was one before. Ghostscript works differently, and
only creates a shape plane if we are in a non-isolated group.
This means that when blending an isolated group back to a non
isolated group, GS uses the "source alpha" in place of the "shape
alpha" to modify the non-isolated groups shape plane.
We update MuPDF to do the same here - it requires some new (small)
routines to do this new type of shape update, but means we carry
smaller amounts of data around overall.
Also, for what little remains of my sanities sake, this helps by
making it easier to compare the debug output from the 2 different
renderers.
|
|
Knockout groups are only created temporarily, and this solves
problems in Altona_Technical_v20_x4.pdf on page 7 on the 'B'.
It seems reasonable that we shouldn't need to have isolated
enabled here, because it's really required for blending the
whole isolated group back.
While we don't propagate "isolated" into "inner" knockout groups, we
DO need to use the incoming isolated value to correctly establish the
backdrop to use.
|
|
|
|
Fixes some issues in Altona test file.
|
|
|
|
Fixes on issue on page 14 of altona test.
|
|
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.
|
|
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.
|
|
|
|
|
|
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 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.
|
|
|
|
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.
|
|
|
|
|
|
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).
|
|
|
|
Option parsing is not implemented yet.
|
