| Age | Commit message (Collapse) | Author |
|---|
|
In order to be able to output images (either in the pdfwrite device or
in the html conversion), we need to be able to get to the original
compressed data stream (or else we're going to end up recompressing
images). To do that, we need to expose all of the contents of pdf_image
into fz_image, so it makes sense to just amalgamate the two.
This has knock on effects for the creation of indexed colorspaces,
requiring some of that logic to be moved.
Also, we need to make xps use the same structures; this means pushing
PNG and TIFF support into the decoding code. Also we need to be able
to load just the headers from PNG/TIFF/JPEGs as xps doesn't include
dimension/resolution information.
Also, separate out all the fz_image stuff into fitz/res_image.c rather
than having it in res_pixmap.
|
|
PDFDocEncoding for crypt revisions <= 4, UTF-8 for newer.
|
|
Previously we combined the softmask xobject->matrix with the ctm
to make gstate->softmask_ctm at load time. This meant that when
we ran the softmask xobject the xobject->matrix was reapplied a
second time.
The fix is to keep the xobject->matrix out and apply it manually
whereever we use the softmask_ctm (which is just for the bbox
transformation currently).
|
|
|
|
This actually turned out to be far easier than I'd feared; remove the
explicit check that stopped this working, and ensure that we pass the
correct value in for the 'indexed' param.
Add a function to check for colorspaces being indexed. Bit nasty that
this requires a strcmp...
|
|
|
|
Implementations remain unexposed, but this means we can safely
pass functions in shades without having to 'sample' them (though
we may still choose to do this for speed).
|
|
|
|
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!
|
|
|
