| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
The 'producing spots' case is poorly tested, but I believe we
should be keeping the spot information internally, rather than
NULLing it out.
|
|
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.
|
|
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.
|
|
First, we add an fz_page_overprint function to detect if a
page uses overprint. Only PDF implements this currently (other
formats all return false). PDF looks for '/OP true' in any
ExtGState entry.
We make Mutool check this. If it finds it, and spot rendering
is not completely disabled, then it ensures that the separation
object passed to the pixmap into which we draw is non NULL. This
causes the draw device to do overprint simulation.
We ensure that mutool draw defaults to having the spot rendering
mode default to simulation in builds that support it.
Finally, we ensure that if an output intent is set by the document,
and spot rendering is not completely disabled, then we ensure the
seps object is non NULL so that we render to a group in the
specified output intent, and THEN convert down to the required
colorspace for the output.
This should make us match acrobats behaviour.
|
|
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.
|
|
This is a wierd one. After much panicing about this, it seems that all
that is required to get the correct result is to ensure that the
groups used by MuPDF to wrap graphical objects displayed in non-Normal
blend modes is a non-isolated (non-knockout) one.
The PDF spec is written assuming that blending happens at object plotting
time. MuPDF does not work in this way. We only support normal blend
mode plotting.
To achieve non-normal blend modes, we therefore wrap each object in a
group. The object is plotted 'normally', and then the end of the group
causes the blend to be applied as required.
Our plotters *do* know about overprinting, hence only the required
components are changed. By using a non-isolated group, the background
is copied in, and overprint correctly chooses not to alter the
appropriate components.
This means that when blending back, the background components match
the source components for overprinted components. Thus (to put it
in terms used in the PDF spec) cb = cs for all overprinted components.
Hence if we use B(cb,cs) = cs (i.e. normal blend mode), we get what
is required by CompatibleOverprint mode.
Thus plotting into our group 'Normally, with overprint', and then
blending back with the specified blend mode, appears to give exactly
what we need.
|
|
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.
|
|
|
|
|
|
|
|
We were failing to allow for the fact that the source pixmap
is premultiplied, meaning we were squaring the alpha each
time.
|
|
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.
|
|
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.
|
