| Age | Commit message (Collapse) | Author |
|---|
|
These got broken during the fz_rect/fz_matrix pass-by-value
changes.
|
|
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.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
Update separations interface further to cope with whether spots
should be rendered separately, or as composite colors.
|
|
|
|
|
|
|
|
It seems likely that we'll want people to able to use the MuPDF
C API as well as the MuOfficeLib helper lib. We therefore need
a way to get fz_context and fz_document values out of MuOfficeLib.
Potential problems exist with people calling MuPDF C API functions
using an fz_context that is in use elsewhere. Similarly, if an
fz_document is in use in a background thread (for instance in a
page render), we need to ensure that it can't be used at the same
time elsewhere.
We therefore provide MuOffice{Lib,Doc,Page}_run functions that
allow this to happen safely. This largely insulates callers from the
complexities of having to clone contexts etc, it safely ensures
that exceptions cannot be propogated beyond the topmost fz_try/
fz_catch, and it ensures that appropriate locking is used.
|
|
Avoid using statics to hold the mutexes. This is safer for
multiple-instantiation.
|
|
|
