| Age | Commit message (Collapse) | Author |
|---|
|
Currently, our API uses static inlines for fz_lock and
fz_unlock, the definitions for which depend on whether
we build NDEBUG or not. This isn't ideal as it causes
problems when people link a release binary with a debug
lib (or vice versa).
We really want to continue to use static inlines for the
locking functions as used from MuPDF, as we hit them
hard in the keep/drop functions.
We therefore remove fz_lock/fz_unlock from the public API
entirely. Accordingly, we move the fz_lock/fz_unlock
static inlines into fitz-imp.h (an internal header),
together with the fz_keep_.../fz_drop_... functions.
We then have public fz_lock/fz_unlock functions for any
external callers to use that are free of compilications.
At the same time, to avoid another indirection, we change
from holding the locking functions as a pointer to a
struct to a struct itself.
|
|
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
Adjust the decode array to allow for the fact that the default
decode is done by the ICC code.
|
|
|
|
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.
|
|
|
|
|
|
Both bandwriter and document_writer interfaces cope with multi
page docs.
Update mudraw to output pclm format too.
Incorporates fixes from Tor.
|
|
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!
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Also save link coordinates in outline nodes.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
Remove superfluous '%' character in the comment with binary bytes.
|
|
|
|
The logic for detecting and stripping alpha channels was subtly wrong.
Simplify it, and also make it cope with spot colors.
|
|
|
|
|
|
|
|
|
|
|
