| Age | Commit message (Collapse) | Author |
|---|
|
Currently each xref in the file results in an array from 0 to
num_objects. If we have a file that has been updated many times
this causes a huge waste of memory.
Instead we now hold each xref as a list of non-overlapping subsections
(exactly as the file holds them).
Lookup is therefore potentially slower, but only on files where the
xrefs are highly fragmented (i.e. where we would be saving in memory
terms).
Some parts of our code (notably the file writing code that does
garbage collection etc) assumes that lookups of object entry pointers
will not change previous object entry pointers that have been
looked up. To cope with this, and to cope with the case where we are
updating/creating new objects, we introduce the idea of a 'solid'
xref.
A solid xref is one where it has a single subsection record that spans
the entire range of valid object numbers for a file. Once we have
ensured that an xref is 'solid', we can safely work on the pointers
within it without fear of them moving.
We ensure that any 'incremental' xref is solid.
We also ensure that any non-incremental write makes the xref solid.
|
|
pdf_lookup_page_loc_imp currently throws if any object in the page tree
is neither a /Pages node nor a /Page leaf. This unnecessarily rejects
slightly broken documents such as the ones from
https://code.google.com/p/sumatrapdf/issues/detail?id=2582 and
https://code.google.com/p/sumatrapdf/issues/detail?id=2608 .
pdf_count_pages_before_kid currently wrongly throws if a /Pages node
doesn't contain any kids and correctly states so (which even seems to
be permitted by the PDF specification).
|
|
In load_sample_func, the stream is not closed and thus leaked if one of
the fz_read_byte or fz_read_bits calls throws (which might happen e.g.
on a Deflate data error).
In pdf_load_compressed_inline_image, the allocated buffer is not freed
if one of the stream initializers or the tile creation throws
(fz_open_leecher does not take ownership of the stream).
|
|
|
|
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.)
|
|
Use the actual ranges from the cpt-to-gid cmap to optimize the
remapping of ToUnicode cmaps from cpt-to-unicode into gid-to-unicode
format.
|
|
When inverting the CMap to create a ToUnicode, first check the actual
range of input characters rather than relying only on the codespace
range list.
|
|
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.
|
|
Even though the encryption key length isn't supposed to be taken from
the encryption dictionary's /Length for crypt version 4, other readers
such as Adobe's still use that value if a crypt filter's /Length is
missing.
See https://code.google.com/p/sumatrapdf/issues/detail?id=2710 for a
document where this makes a difference (or simply remove /Length from
the crypt filter in any document encrypted with crypt version 4 and an
AESV2 crypt filter).
|
|
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.
|
|
Don't rely on the csize and usize fileds being set in the individual
entry headers.
|
|
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.
|
|
If garbage is appended to an encrypted document, there could be another
trailer with /ID but without /Encrypt . The repairing code currently
always uses the last encountered values, but replacing the /ID value
alone can cause decryption to break. One possible solution is to
use the /ID value only when there's either none yet, when there's no
/Encrypt or when there's a matching /Encrypt in the same trailer.
See https://code.google.com/p/sumatrapdf/issues/detail?id=2697 for a
document which Adobe Reader is able to read but MuPDF isn't (it used
to before pdf_lex_no_string was introduced, but that's accidental).
|
|
xps_deobfuscate_font_resource assumes that a font has at least 32 bytes
of data required for deobfuscation. If a broken font has less data,
the buffer overflows.
Also, the data buffer is leaked when fz_new_font_from_buffer throws.
|
|
|
|
|
|
Invert the boolean test to mean what is actually intended.
Fixes bug 695419.
|
|
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
|
