| Age | Commit message (Collapse) | Author |
|---|
|
Call these from the PDF interpreter. Make the DisplayList and
Trace devices cope.
Use these in the SVG output device.
|
|
Previously the trailing null terminator would not be written if the
formatted string ended up longer than the buffer.
|
|
|
|
|
|
|
|
fz_write_byte forgot to write the byte after needing to flush
the buffer.
|
|
SIZE_MAX is surprisingly supposed to be in stdint.h, but Android
headers for API levels < 21 accidentally put SIZE_MAX in limits.h.
Headers for API levels >= 21 correctly moved SIZE_MAX to stdint.h.
This is the situation for Android NDK r14 and earlier.
Android NDK r15 and later implement a header unification strategy:
all sets of headers for each API level are combined into a single
set of headers covering all API levels. Any differences are
expressed by #ifdeffing on __ANDROID_API__. When this was done
the moving of SIZE_MAX from limits.h to stdint.h was kept and,
importantly, no #ifdefs were used in limits.h/stdint.h concerning
SIZE_MAX. This means that the move of SIZE_MAX was retroactively
introduced for API levels < 21 in Android NDK r15 and later.
For this reason whenever mupdf uses SIZE_MAX it must include both:
* stdint.h (not just in order to follow the POSIX specification,
but also to compile successfully using Android NDK r15 and later)
* and limits.h (in order to compile successfully using Android NDK
r14 and earlier)
Hence these need to include both stdint.h and limits.h, because:
* source/fitz/memory.c uses SIZE_MAX
* source/fitz/store.c uses SIZE_MAX
The mupdf header include/mupdf/fitz/system.h includes stdint.h so
any file that includes system.h will automatically have stdint.h
This is true for both files. limits.h on the other hand needs to
be explicitly included by whomever uses SIZE_MAX. This was already
done by source/fitz/store.c but not by source/fitz/memory.c, but
has now been added.
|
|
|
|
Previously mupdf would silently ignore this situation and leave the
buffer uninitialized leading to further issues. Thanks to oss-fuzz
for reporting.
|
|
Thanks to oss-fuzz for reporting.
|
|
|
|
|
|
This is needed to simplify the way the bytes for hashing are
passed to pkcs7 functions.
|
|
For TIFF it was not just the colorspace, but other data as well.
|
|
|
|
|
|
A lot of EPUB pool allocated data is much smaller than the default size,
leading to a lot of wasted memory.
|
|
|
|
If fz_new_pixmap_with_bbox() threw conv would be NULL and temp would
be pointing to a pixmap that would be dropped 2 times.
If fz_clone_pixmap_area_with_different_seps() threw temp and conv
would be pointing to the same pixmap that would be dropped 3 times.
|
|
Without this change future calls to fz_fin_cached_color_converter()
will try to dereference the already freed pointer.
|
|
|
|
|
|
|
|
An earlier commit changed the mode used to open a file for saving so that
it could also be read from. The mode used was rb+ independently of whether
the saving mode was incremental or not. Doing so neglected that for
non-incemental saves the file may not already exist in which case opening
rb+ will fail. This commit arranges that wb+ is used in the non-incremental
case.
|
|
This provides a way for some output streams to also be read, a feature
needed for the sake of document signing. Currently this is supported only
for file output.
|
|
Do not throw an exception, just ignore the faulty color profile.
|
|
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.
|
