| Age | Commit message (Collapse) | Author |
|---|
|
The lock checking functions are always enabled in debug mode, but
since they are not thread safe they may not be used in a
multi-threaded application. Multi-threaded applications are
required to set their own locking functions so the lock checking
functions should only be run if the default locking functions
are in use.
|
|
|
|
|
|
The subarea rect used for lookups could mismatch the subarea returned
by the get_pixmap function due to adjusting to whole bytes. Refactor
and use a common subarea adjustment function.
Many image formats which do not support subarea tiles will decode
and cache the full image, so if a subarea tile cannot be found,
look for the full image tile as well.
|
|
|
|
|
|
|
|
|
|
Previously the copy had as many reference counts as the original
pixmap which lead to leaks of pixmaps.
|
|
This needs adding a fz_xml_doc type to hold the pool.
|
|
|
|
Well, at least not to crash.
|
|
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.
|
|
|
|
|
|
We NEED lcms2art (the artifex branch) and cannot build with stock lcms2.
Disable ICC support if the lcms2 thirdparty library is not present.
|
|
If we attempt to make an icc colorspace in a NO_ICC build, throw
an exception. This stops us ending up with 'UNKNOWN' colorspaces
in the system.
|
|
If the move due to a closepath is infinitessimal, fz_stroke_lineto
skips it as it cannot accurately figure out what the direction is.
It appears we have had some code in fz_stroke_closepath to cope
with exactly this case, but it does the wrong thing. This dates
back all the way to the initial import of the code, so presumably
it worked at some point, and stopped working somewhere along the
line.
|
|
Use android logging for throw/warn like we do with OutputDebugString
on windows.
|
|
When stroking paths if we meet segments of 0 length, we can't
determine a direction, thus start/end caps are omitted. Line
widths are irrelevant, and we thus render nothing.
(Note that moves on their own do NOT count as a line segment).
The exception to this is where we are using round caps, whereupon
whatever direction the path is taken to have, the appearance will
be the same - and this we render the segment as a dot.
We have code in the renderer already to do this, but it looks to
me like it could be fooled into leaving a dot by us first doing
a move, a lineto the same point, and then a lineto to somewhere
else. The current code sets the 'dot' value to 1 when it detects
the degenerate line, and doesn't reset when it meets a
non-degenerate line later.
Accordingly I've changed the code here to account for such a
circumstance.
This produces no diffs in the cluster testing, but seems more
correct to me.
|
|
|
|
Thanks to Tamir Evan for this tweak.
|
|
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.
|
|
|
|
|
|
|
|
TODO: Implement visual to logical reordering on the fly when building
the structured text line.
|
|
|
|
Also, fix mudraw messages about what types can be banded.
|
|
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).
|
|
|
|
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 so that we can have bgr formatting with
something other than the default sRGB
|
