Age | Commit message (Collapse) | Author |
|
|
|
In file included from scripts/cmapdump.c:19:
scripts/../source/fitz/ftoa.c:30:23: warning: redefinition of typedef 'ulong' is a C11 feature [-Wtypedef-redefinition]
typedef unsigned long ulong;
^
scripts/../source/fitz/strtod.c:30:23: note: previous definition is here
typedef unsigned long ulong;
^
1 warning generated.
(Apparently in earlier versions of clang this is an error.)
|
|
The dtoa function is for doubles (which is what MuJS uses) but for MuPDF
we only need and want float precision in our output formatting.
|
|
This is required for XPS, as otherwise images can be completely
omitted.
|
|
|
|
Add a whitespace preserving mode, for future use with XHTML.
Also parse XHTML entities. This is not strictly according to spec,
but for properly formed XML documents it should not matter.
|
|
Add a new class of errors and use them to abort interpretation when
the test device detects a color page.
|
|
With this change, all 32-bit values read from untrusted data through
read_value are compared unmodified in order to prevent unintended
integer overflows during the comparison.
|
|
Rather than decoding entire image only to give up after we find the
very first pixel is color, add code so that the test-device can
treat the image as a stream. This means that (for most image types
at least) we can bale out without decoding everything.
This reduces the runtime of 3001Pages.pdf from 14 minutes to 18 seconds.
|
|
Add some #definery for platforms where NAN and INFINITY aren't
defined in std headers.
|
|
We were failing to drop each pixmap after testing it, and to free
the test_device structure at the end of each run.
|
|
|
|
|
|
|
|
When we detect that a page is color, set the ignore image hint
to avoid us loading future images. The overhead on loading
images is not generally huge, except for JPEG2000 ones, which
currently require decoding at load time. This therefore saves
lots of time for such files.
Also, a tiny tweak to ignore page components with 0 alpha.
|
|
The original version of the test-device could characterise pages
as being grayscale/color purely based on the colorspaces used.
This could easily be upset by grayscale images or shadings that
happened to be specified in non-grayscale colorspaces however.
We now look at the actual shading and image color values, and use
a threshold value to allow for some measure of rounding errors in
color values that are in practice grayscale.
|
|
Let either or both of the 'prepare' and 'process' callbacks be no-ops.
|
|
win32 supports tinting, but cannot change the color from the default.
|
|
|
|
We build MuPDF without NDEBUG defined in order to check assertions but
don't want Visual Studio's Output console flooded with warnings for
broken documents. So instead of always defining USE_OUTPUT_DEBUG_STRING
for debug builds under Windows, allow the VS solutions to define it
when desired and to omit it when not.
|
|
Adobe Reader and Microsoft XPS viewer differ in their handling of
non-empty dashed strokes where the phase is 0: Adobe Reader considers
these to be faulty and omits them while Microsoft XPS Viewer renders
them the same as an empty dash (i.e. solid).
This patch makes Fitz no longer render such strokes and ensures that
MuXPS never emits them so that the desired behavior results (this is
the easier implementation since XPS rendering code renders stroked
paths in a single location whereas PDF rendering does it all over the
place).
See https://code.google.com/p/sumatrapdf/issues/detail?id=2339 for a
testcase.
|
|
Invert the boolean test to mean what is actually intended.
Fixes bug 695419.
|
|
fz_image::n is used inconsistently: Sometimes it includes the alpha
channel and sometimes it doesn't. At the point where
fz_unblend_masked_tile is called, it doesn't.
|
|
|
|
The TIFF specification seems to only allow for 4-bit and 8-bit
colormaps. However at least Microsoft's XPS viewer also accepts 1-bit
colormaps and our current code handles this case already anyway.
See https://code.google.com/p/sumatrapdf/issues/detail?id=2562 for a
sample document.
|
|
Don't convert and compare color if we already know the page has color.
|
|
Currently only tests for the presence of non-grayscale color.
|
|
|
|
|
|
(Revert the fix for potential memory leak - there wasn't a potential memory
leak as the device only takes ownership of it's display list if
dev->free_user is set).
This reverts commit ada560eb015e7b2208c492d47f28da8093733c4a.
|
|
|
|
|
|
If an iOS app uses too much memory, the OS asks it to free up some space.
If it doesn't do so in a timely manner, it will get a second warning before
being killed by the OS.
In other platforms, where malloc() return NULL in OOM, the store scavenger
releases memory when mallocs fail. In iOS, mallocs usually never return NULL
because the app is killed before this can happen. Therefore, we need to
initiate a scavenge from the low memory notification instead.
We evict the store to 50% of its current size when a memory warning occurs
when it is in the foreground, and 0% when a memory warning occurs whilst
it is in the background. Having said this, I didn't manage to get a background
warning to occur, presumably because we don't request background execution
Therefore, I think in practice the OS just kills the process. However, this
will be useful if we ever add background execution.
|
|
|
|
When throwing an error during fz_alpha_from_gray, the stack depth
can get confused. Fix this by moving some more code into the
appropriate fz_try().
In the course of fixing this bug, I added some new optional debug
code to display the stack level as it runs. This is committed here
disabled; just change the appropriate #define in draw-device.c to
enable it.
Also, add some code to run_xobject, to avoid throwing in an fz_always()
clause.
|
|
If we hit an out of memory error in fz_draw_end_mask, then pop the
stack, and rethrow. Ensure that the generic device code catches this
error and sets the error_depth to 1 so that the final pop is ignored.
|
|
|
|
We used to extract the outline using the combined TM*CTM matrix and
use the identity transform for stroking, thus ending up with the wrong
line width.
If we instead extract using the TM and then stroke with the CTM we get
the correct results.
|
|
|
|
When I changed the stream implementations to use implementation
specific buffers, rather than a generic public one in every fz_stream,
I changed fz_read_byte to only get a single byte at a time.
I noted at the time that the underlying stream was free to decode
larger blocks if it wanted too, but I forgot to actually do this for
the flate decoder. Fixing this here should solve the speed issues.
|
|
|
|
Grow the edge list using an exponential realloc pattern.
Use qsort for huge paths and only fall back to the simple
shell sort for small paths.
|
|
|
|
This adds a custom memory management layer between libjpeg and the calling
app - in such a way that the code can be shared between mupdf and
Ghostscript/PDL.
|
|
Don't let a glyph's bbox be too much bigger than the font bbox.
|
|
|
|
Same as for fz_bbox_fill_image_mask, fz_bbox_clip_image_mask must
transform the unit rectangle to get the bounding bbox.
|
|
There are two issues where variables may be used unitialized:
* extract_exif_resolution fails to set xres and yres for JPEG images if
there's no valid resolution unit (mainly affects XPS documents)
* xps_measure_font_glyph uses hadv and vadv unitialized if the glyph id
isn't valid (i.e. if FT_Get_Advance fails)
|
|
Thanks to Triet Lai.
|
|
|