| Age | Commit message (Collapse) | Author |
|---|
|
I'd half finished this code before, and only spotted the missing
bits while cleaning up some warnings.
|
|
Some -Wshadow ones, plus some 'set but not used' ones.
|
|
|
|
|
|
This requires a slight change to the device interface.
Callers that use fz_begin_tile will see no change (and no caching
will be done). We add a new fz_begin_tile_id function that takes an
extra 'id' parameter, and returns 0 or 1. If the id is 0 then the
function behaves exactly as fz_being_tile does, and always returns 0.
The PDF and XPS code continues to call the old (uncached) version.
The display list code however generates a unique id for every
BEGIN_TILE node, and passes this in.
If the id is non zero, then it is taken to be a unique identifier
for this tile; the implementer of the fz_begin_tile_id entry point
can choose to use this to implement caching. If it chooses to ignore
the id (and do no caching), it returns 0.
If the device implements caching, then it can check on entry for a
previously rendered tile with the appropriate matrix and a matching id.
If it finds one, then it returns 1. It is the callers responsibility
to then skip over all the device calls that would usually happen to
render the tiles (i.e. to skip forward to the matching 'END_TILE'
operation).
|
|
|
|
This fixes bug #693664, and also simplifies app code.
The example file attached to the bug produces strange results, but that
is because the QuadPoint information is incorrect.
|
|
Seen with the test file from bu 693677. When we read a file in, we
read the trailer, and the encrypt object before we start to decrypt
other objects. These objects do not make it into the xref table though.
When we write a file out, we run through the file reading in objects
prior to writing them out; when we read in the trailer and the encrypt
object we therefore try to decrypt them, giving errors.
To avoid these errors, put the trailer and the encrypt object into the
xref table when they are first read.
This solves all but 1 problem when cleaning this file with "-dif" (as
the signature object contains a digest block of data that is unencrypted).
This solves all but 3 problems when cleaning this file with "-difggg";
the signature object, and one orphan copy of the crypt dictionary that
is reported twice.
|
|
|
|
Due to an unfixed FIXME, the Outline details were always being detected
as being free and hence dropped.
Solve this, ensuring they go into the right part of the file. Also
ensure that Names and Dests go into the final section too.
|
|
My previous JPX softmask commit was forcing fz_alpha_to_gray to be
called with luminosity = 0, which meant it ended up with solid pixels.
This fix actually reverts the line to what it was before (but not
the rest of the commit). hivemind.pdf is still far from rendering
correctly though.
|
|
Use of the bbox device to derive the area of the display list can lead
to bad results because of heuristics used to handle corners of stroked
paths.
|
|
|
|
Also, in the app, protect against exceptions thrown due to unknown
annotation types.
|
|
If the colorspace given in the dictionary of a JPX image differs from
the colorspace given in the image itself, decode to the native image
format, then convert.
This goes a long way towards fixing "1439 - color softmask fails to
draw jpx image.pdf" (aka hivemind.pdf). The lack of transfer function
support hopefully explains the rest.
|
|
|
|
Also change the way we pass the text rectangles so that
non-axis-aligned ones can be permitted, and relocate the code that
calculates the strike-out lines from the bounding boxes
|
|
|
|
|
|
Avoid heap overflow in the error case in fz_end_tile.
Avoid leaking all previously loaded annotations from pdf_load_annots
if pdf_is_dict throws an exception.
Various whitespace fixes.
Many thanks to zeniko.
|
|
Added primarily for use by SumatraPDF.
Thanks to zeniko.
|
|
Thanks to zeniko.
|
|
Thanks to zeniko.
|
|
Thanks to zeniko.
|
|
Thanks to zeniko.
Also ensure that pdf_free_annot copes with NULL.
|
|
strncpy is *not* the correct function to use. It does not null terminate,
and it needlessly zeroes past the end. It was designed for fixed length
database records, not strings. Use fz_strlcpy and strlcat instead.
|
|
|
|
|
|
This is faster on ARM in particular. The primary changes involve
fz_matrix, fz_rect and fz_bbox.
Rather than passing 'fz_rect r' into a function, we now consistently
pass 'const fz_rect *r'. Where a rect is passed in and modified, we
miss the 'const' off. Where possible, we return the pointer to the
modified structure to allow 'chaining' of expressions.
The basic upshot of this work is that we do far fewer copies of
rectangle/matrix structures, and all the copies we do are explicit.
This has opened the way to other optimisations, also performed in
this commit.
Rather than using expressions like:
fz_concat(fz_scale(sx, sy), fz_translate(tx, ty))
we now have fz_pre_{scale,translate,rotate} functions. These
can be implemented much more efficiently than doing the fully
fledged matrix multiplication that fz_concat requires.
We add fz_rect_{min,max} functions to return pointers to the
min/max points of a rect. These can be used to in transformations
to directly manipulate values.
With a little casting in the path transformation code we can avoid
more needless copying.
We rename fz_widget_bbox to the more consistent fz_bound_widget.
|
|
|
|
|
|
|
|
Also simplify some other functions using pdf_dict_puts_drop
|
|
|
|
|
|
|
|
|
|
Bug 693527 points out that we fail to spot Jpeg 2000 images that
have themselves as their own SMask and enter an infinite loop.
We extend the code by passing the forcemask parameter in exactly the
same way as the non-JPEG 2K code does.
Thanks to Jarkko Poyry for spotting this, reporting it, and suggesting
the fix.
|
|
When adding code to spot identical streams, I got the logic in
a test reversed as a result of a last minute change. Corrected here.
Thanks to zeniko for pointing this out.
|
|
When writing pdf files, we currently have the option to remove duplicate
copies of objects; all streams are treated as being different though.
Here we add the option to spot duplicate streams too.
Based on a patch submitted by Heng Liu. Many thanks!
|
|
If a PDF xref subsection is broken in the wrong place, we can get
NULL back from fz_strsep, which causes a SEGV when fed to atoi.
Add a new fz_atoi that copes with NULL to avoid this.
Problem found in a test file, 3959.pdf.SIGSEGV.ad4.3289 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
|
|
If a colorspace refers to itself as a base, we can get an infinite
recursion and hence stack overflow. Thanks to zeniko for pointing out
that this occurs in embedded CMAPs and stitching functions. Also
solved here.
To avoid having to keep a long list of the objects we've traversed
through, extend the pdf_dict_mark functions to work on all pdf objects,
and hence rename them as pdf_obj_mark etc. Thanks to zeniko again for
feedback on this way of working.
Problem found in a test file, 3882.pdf.SIGSEGV.99.3204 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
When parsing a (broken) PDF stream, we can forget an existing
parsed object when we parse another one. Check for us having
one and free it if we do.
Problem found in a test file, 3289.pdf.asan.77.2545 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
If the Function entry does not point to either a dictionary or an
array, we should give up, otherwise we deference a NULL pointer.
Problem found in a test file, 1013.pdf.SIGSEGV.8a7.18 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
|
|
When cleaning a file with a corrupt stream in it, historically mupdf
would give up when it encountered such a stream. This is often not
what is desired, as information can be lost.
The changes herein allow us to use our best efforts when reading
a stream, so that broken streams are reproduced in the output
cleaned file.
Problem found in a test file, pdf_001/2599.pdf.asan.58.1778 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
When reading a CMAP with values out of range, we can go into a
very long loop emitting the same pair of warnings.
Spot the error case earlier and this give a nicer report.
Problem found in a test file, 3192.pdf.SIGSEGV.b0.2438 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
An unused dictionary reference could be left dangling. Simple fix
is to drop the reference after use.
Problem found in a test file, 2785.pdf.asan.6d.1985 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
When running a softmask, we remove the softmask from the gstate,
then run the group contents, then put the softmask back.
If the gstate stack is moved in the meantime (due to it being
realloced for extension), we can end up with it being moved.
We therefore must recalculate gstate before writing again.
Problem found in a test file, pdf_001/2599.pdf.asan.58.1778 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
