| Age | Commit message (Collapse) | Author |
|---|
|
Any pixmap writers that can handle data with an alpha plane
should accept that data in premultiplied form, and write it out
appropriately for the file format.
This avoids the need to unpremultiply data in mudraw, and solves
the issue we were seeing where we want the png writer to be able
to cope with premultiplied data (such as for the debug blending
routines) and unpremultiplied data (such as that given after
mudraw has unpremultiplied the data).
|
|
When cleaning a pdf file, various lists (of pdf_xref_len length) are
defined early on.
If we trigger a repair during the clean, this can cause pdf_xref_len
to increase causing an overrun.
Fix this by watching for changes in the length, and checking accesses
to the list for validity.
This also appears to fix bugs 698700-698703.
|
|
Adopt Josephs suggested fix for arithmetic overflow.
Thanks to Kan-Ru Chen for spotting the problem.
|
|
|
|
|
|
|
|
|
|
So it can be used in the filter pdf_processor too.
|
|
|
|
Closing flushes output and may throw exceptions.
Dropping frees the state and never throws exceptions.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
|
|
|
|
When mapping spots down to process colors, don't try to map
disabled spots.
|
|
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.
|
|
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.
|
|
|
|
These are called from fz_new_image_from_buffer.
|
|
|
|
|
|
This is needed for gsview where I would like to know the output intent
of the PDF document as well as the color space for any image documents
that we open. That way users can better know how best to color manage
the documents.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is needed so that we can have bgr formatting with
something other than the default sRGB
|
|
|
|
|
|
|
|
As seen with ../tests_private/comparefiles/Bug693541.pdf
This file has an RGB isolated group, within which it renders a
spot only shading. We therefore create the RGB+S+A pixmap, and
set it to all zeros. The shading is drawn to a new S+A pixmap.
The problem comes when the code writes the S+A pixmap to the
RGB+S+A one.
When we set the alpha values to be non zero in an additive space
we need to reset the process components to be full (scaled by
alpha).
|
|
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.
|
|
|
|
|
