| 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.
|
|
It was only ever calling fz_lock for its own lock. This was
an abuse at best, and could potentially have caused trouble
with the deadlock detection code. Instead, lock the same lock,
but do so using custom (static) functions.
|
|
|
|
|
|
|
|
|
|
|
|
We currently don't handle errors here, but if we do in the future we
don't want stale pointers lying around.
|
|
|
|
|
|
GLFW doesn't build on Visual Studio 2005 anymore, and I don't have time to keep
up with the changes.
So, we're switching back to FreeGLUT, which is more stable.
I've added the two missing features that made us switch to GLFW in the first
place: input methods and system clipboard support.
If MuPDF is compiled with our version of FreeGLUT, we now use these functions:
* glutKeyboardExtFunc
* glutSetClipboard
* glutGetClipboard
|
|
TODO: Implement visual to logical reordering on the fly when building
the structured text line.
|
|
|
|
|
|
This affects the given character bboxes.
|
|
|
|
If nothing else, this avoids warnings on VS2005.
|
|
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).
|
|
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).
|
