| Age | Commit message (Collapse) | Author |
|---|
|
File references escaped deletion in previous commit.
|
|
|
|
|
|
|
|
I made a last minute change to make pdf_open_filter do the locking,
and forgot to remove the call to lock from pdf_open_stream_with_offset.
Fixed here. Thanks to Radu Lazar for pointing this out.
|
|
|
|
I forgot to update Android and iOS projects with the extra
arg to fz_new_context. Fixed here.
|
|
This is a significant change to the use of locks in MuPDF.
Previously, the user had the option of passing us lock/unlock
functions for a single mutex as part of the allocation struct.
Now we remove these entries from the allocation struct, and
make a separate 'locks' struct. This enables people to use
fz_alloc_default with locking.
If multithreaded operation is required, then the user is
required to create FZ_LOCK_MAX mutexes, which will be locked
or unlocked by MuPDF calling the lock/unlock functions within
the new fz_locks_context structure passed in at context creation.
These mutexes are not required to be recursive (they may be, but
MuPDF should never call them in this way). MuPDF avoids deadlocks
by imposing a locking ordering on itself; a thread will never take
lock n, if it already holds any lock i for which 0 <= i <= n.
Currently, there are 4 locks used within MuPDF.
Lock 0: The alloc lock; taken around all calls to user supplied
(or default) allocation functions. Also taken around all accesses
to the refs field of storable items.
Lock 1: The store lock; taken whenever the store data structures
(specifically the linked list pointers) are accessed.
Lock 2: The file lock; taken whenever a thread is accessing the raw
file. We use the debugging macros to insist that this is held
whenever we do a file based seek or read. We also insist that this
is never held when we resolve an indirect reference, as this can
have the effect of moving the file pointer.
Lock 3: The glyphcache lock; taken whenever a thread calls freetype,
or accesses the glyphcache data structures. This introduces some
complexities w.r.t type3 fonts.
Locking can be hugely problematic, so to ease our minds as to
the correctness of this code, we introduce some debugging macros.
These compile away to nothing unless FITZ_DEBUG_LOCKING is defined.
fz_assert_lock_held(ctx, lock) checks that we hold lock.
fz_assert_lock_not_held(ctx, lock) checks that we do not hold lock.
In addition fz_lock_debug_lock and fz_lock_debug_unlock are used
on every fz_lock/fz_unlock to check the validity of the operation
we are performing - in particular it checks that we do/do not already
hold the lock we are trying to take/drop, and that by taking this
lock we are not violating our defined locking order.
The RESOLVE macro (used throughout the code to check whether we need
to resolve an indirect reference) calls fz_assert_lock_not_held to
ensure that we aren't about to resolve an indirect reference (and
hence move the stream pointer) when the file is locked.
In order to implement the file locking properly, pdf_open_stream
(and friends) now lock the file as a side effect (because they
fz_seek to the start of the stream). The lock is automatically
dropped on an fz_close of such streams.
Previously, the glyph cache was created in a context when it was first
required; this presents problems as it can be shared between several
contexts or not, depending on whether it is created before the
contexts are cloned. We now always create it at startup, so it is
always shared.
This means that we need reference counting for the glyph caches.
Added here.
In fz_render_glyph, we take the glyph cache lock, and check to see
whether the glyph is in the cache. If it is, we bump the refcount,
drop the lock and returned the cached character. If it is not, we
need to render the character.
For freetype based fonts we keep the lock throughout the rendering
process, thus ensuring that freetype is only called in a single
threaded manner.
For type3 fonts, however, we need to invoke the interpreter again
to render the glyph streams. This can require reentrance to this
routine. We therefore drop the glyph cache lock, call the
interpreter to render us our pixmap, and take the lock again.
This dropping and retaking of the lock introduces a possible race
condition; 2 threads may try to render the same character at the
same time. We therefore modify our hash table insert routines to
behave differently if it comes to insert an entry only to find
that an entry with the same key is already there.
We spot this case; if we have just rendered a type3 glyph and when
we try to insert it into the cache discover that someone has beaten
us to it, we just discard our entry and use the cached one.
Hopefully this will seldom be a problem in practise; to solve it
properly would require greater complexity (probably involving
spotting that another thread is already working on the desired
rendering, and sleeping on a semaphore until it completes).
|
|
Rather than having a custom build step that generates the font
and cmap "generated" files, have it as a separate project.
This enables us to nuke the generated directory as part of the
clean step, and to list the files in the solution explorer.
|
|
|
|
When cloning a context, it's generally best to return your new
context, rather than the one you cloned from.
|
|
|
|
|
|
|
|
We used to discard all events until we got a MapNotify, but some
window managers send the ConfigureNotify before the window is
mapped.
|
|
Prevents segfaults when revisiting pages and trying to
access the link object that was freed too early.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update xps path handling to cope with URLs.
Fix premature freeing of links.
Spot remote URLs and use appropriate link type.
|
|
Currently, this only works with local links.
When running the page, check for NavigateUri entries; if found,
and that page is not already marked as having resolved it's links,
add a new link entry to doc->current_page links. When the page
finishes running, mark the page as having resolved it's links.
This avoids the links being generated multiple times.
Update the mupdf viewer to use these links - but only AFTER the
page has been run.
|
|
And mucbz.h.
|
|
|
|
The operator list in parse_code is binary searched through, hence
operators must be in alphabetical order. Thanks to Brian Adams for
pointing out the mistake here.
|
|
Add 2 missing cases to parse_code.
|
|
Remove remnants of old tests that are no longer required.
|
|
More aesthetically pleasing version.
|
|
Word space should only be applied when the codepoint is 32, and
is read from a single byte encoding region. Ghostscript gets
this wrong too.
|
|
Just add some fz_try/fz_catches.
|
|
|
|
|
|
|
|
|
|
|
|
Update Android build for new thirdparty.zip.
Small windows fix for pdf_xref -> pdf_document changes.
|
|
This a) improves our branding, and b) avoids conflicts with
other pdf tools out there (pdfinfo etc).
|
|
|
|
Updated thirdparty.zip contains newer jpeg, jbig2 and freetype code.
|
|
|
|
This brings MuXPS up to date with GhostXPS as of today.
The commits pulled in are:
856ecdc Whitespace fixes for parsing dashed line attributes
91dc749 Whitespace fixes while parsing points.
This commit is tweaked from the original, and the
changes will be pushed back into GhostXPS shortly.
a298a05 Tiff premultiplied/non-premultiped alpha differences.
No changes required for this, as we hold images
premultiplied already (and already cope with
premultiplying where required). Some changes to
comments and cleanup code to avoid leaks though.
|
|
On extreme downscales, the weights for each pixel can all round to
zero; this results in no weights being stored at all, and causes
either an exception or a SEGV. The simple fix is to ensure that the
first pixel that's actually in range (and there will always be one)
always has a weight of at least 1.
Thanks to malc for finding the test cases that lead to this bugfix.
|
