| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
When iterating through blocks, make sure to include
text blocks. After building the char array for a
given line, be sure to add it to the line object.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously the counts and points arrays would leak if
GetFloatArrayRegion() threw an exception.
|
|
Previously the initialization order of init() and the field inited
was not obvious. Move the static block as far up as possible but
make sure that inited is initialized before that. Also add a comment
explaining why.
|
|
Previously when metadata was not found mupdf still tried
to return a string to the caller, but the string was uninitialized.
|
|
|
|
This way the MuPDF library itself only uses fz_snprintf for
consistent formatting.
|
|
|
|
|
|
It should be in "build/$release/thirdparty/freeglut".
|
|
|
|
We NEED lcms2art (the artifex branch) and cannot build with stock lcms2.
Disable ICC support if the lcms2 thirdparty library is not present.
|
|
|
|
Remove code left over from development that is now wrong.
We should have default colorspaces in the system, even in
NON_ICC builds.
|
|
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.
|
|
Also wrap their contents in q/Q, so they can't screw up the
rest of the stream.
|
|
Otherwise we can get empty bbox values.
|
|
Hold 2 instances of a structure, rather than a structure with
2 of each fields in it.
Also, correct the logic for when we send color changes.
|
|
|
|
|
|
|
|
|
|
Popup annotations should never have an appearance stream, but in case
they do we shouldn't draw them.
The Open property is only to toggle whether the GUI should be showing
the Content text editing in a Popup (or Text) annotation, and should
not affect drawing the page.
|
|
|
|
|
|
glutMainLoopEvent does not sleep for events, so use glutMainLoop instead
and destroy the window when 'q' is pressed rather than just setting the
quit flag.
|
|
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.
|
|
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.
|
