| Age | Commit message (Collapse) | Author |
|---|
|
Bug 695377.
|
|
|
|
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.
|
|
Certain glyphs such as found in nested Type 3 font can't be cached.
Currently, the text extraction device doesn't see these as they're sent
only as drawing operations. Sending them also as invisible text fixes
potentially missing letters.
|
|
pdf_page::transparency is supposed to indicate whether a page uses PDF
transparency features. The checks aren't complete, though, which is
relevant for devices which require additional handling for transparency
(such as SumatraPDF's gdiplus_device).
See https://code.google.com/p/sumatrapdf/issues/detail?id=2107 and
https://code.google.com/p/sumatrapdf/issues/detail?id=2540 for
example documents.
|
|
If a PDF document is encrypted but broken, repairing caches all
strings in encrypted form. Clearing the xref after repairing
ensures that strings are returned to API callers as expected.
Cf. https://code.google.com/p/sumatrapdf/issues/detail?id=2610
|
|
Per the ZIP specification, ZIP64 values are only used if the original
value was -1 (i.e. 0xFFFF for 16-bit and 0xFFFFFFFF for 32-bit values).
Microsoft's XPS viewer behaves according to specification and so
should MuXPS.
|
|
fmt_obj calculates whether a string is better hex-encoded or written
using escapes. Due to a bug, '\0' is considered to be escapable same as
'\n' when instead it would have to be written as '\000'. Since UTF-16
strings tend to consist of many '\0' bytes, their octal encoded form is
much longer than their hex encoded form.
The issue is that the first argument to strchr contains an unintended
trailing '\0' which has to be special-cased first.
|
|
PDF documents aren't required to end in a linebreak. Objects however
must start on their own line (in particular for broken documents
relying on reparation). For this reason, a linebreak must be inserted
before starting an incremental update.
|
|
If the two arguments to cbz_strnatcmp are equal (except for leading
zeros), cbz_strnatcmp reads beyond the buffer until it finds differing
bytes or enters a non-readable memory page.
TODO: Should sorting "test01" and "test1" lead to a stable sort order?
|
|
Don't convert and compare color if we already know the page has color.
|
|
Currently only tests for the presence of non-grayscale color.
|
|
|
|
Sort case insensitively in this order:
page-1.jpg
page-2.jpg
page-10.jpg
|
|
I think this is non-standard, but some applications seem to use it.
The email app on Android uses it, despite the fact the original email
actually embedded it as application/octet-stream. I guess the email app
is looking at the filename.
|
|
|
|
|
|
(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.
|
|
Android NDK
(security issue because a variable is used as a format string with no parameters).
|
|
|
|
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.
|
|
Return the null object rather than throwing an exception when parsing
indirect object references with negative object numbers.
Do range check for object numbers (1 .. length) when object numbers
are used instead.
Object number 0 is not a valid object number. It must always be 'free'.
|
|
Replace the DroidSansFallback TTF files with a TTC that has two fonts:
The original and a copy where the OpenType 'vert' substitution
lookup has been pre-applied by copying the uniXXXX.vert glyph data
to uniXXXX.
|
|
pdf_create_document leaks the trailer and in pdf-device.c many objects
are inserted into dictionaries using pdf_dict_puts and leaked instead
of using pdf_dict_puts_drop.
|
|
...like the one Microsoft Word generates.
|
|
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.
|
|
|
|
Various functions (such as fz_begin_group) handle errors internally
by use of the error_depth parameter. This means that if we call
them, we MUST ensure that we call the appropriate closing function.
Similarly, if we don't call them, we should NOT call the closing
function.
In order to ensure we do this correctly, we introduce a cleanup_state
variable that says which ones we tried to call.
This cures the original bug.
|
|
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.
|
|
Without this, comparefiles/Bug695086 renders the barcode test upside
down.
|
|
|
|
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.
|
|
Fixes bug introduced in commit 1679c1e7a89ae62260fd84ce55c6bef376c6e6ba:
Optimize UniXXX CMap files.
|
|
|
|
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.
|
|
See bug 693314 (file Z23-04.pdf) for an example file.
|
|
key length.
This reverts commit b1ed116091b790223a976eca2381da2875341e10.
The key length for V==2 must be 40 <= length <= 128.
The key length for V==4 is not taken from the /Length entry.
|
|
|
|
|
|
|
|
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)
|
