| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In preparation for work on progressive loading, update the exception
handling scheme slightly.
Until now, exceptions (as thrown with fz_throw, and caught with
fz_try/fz_catch) have merely had an informative string. They have
never had anything that can be compared to see if an error is of
a particular type.
We now introduce error codes; when we fz_throw, we now always
give an error code, and can optionally (using fz_throw_message)
give both an error code and an informative string.
When we fz_rethrow from within a fz_catch, both the error code and
the error message is maintained. Using fz_rethrow_message we can
'improve' the error message, but the code is maintained.
The error message can be read out using fz_caught_message() and the
error code can be read as fz_caught().
Currently we only define a 'generic' error. This will expand in future
versions to include other error types that may be tested for.
|
|
Also correct a comment
|
|
|
|
|
|
|
|
|
|
|
|
Patch from "andyhan2000" to make the ink annotations smoother.
|
|
Thanks to zeniko for spotting these.
|
|
Spotted by Vincent Torri. Many thanks!
|
|
Remove fz_free_display_list from the API; instead use fz_drop_display_list.
|
|
When creating the previous commit, I considered an alternative way
of working. While we didn't use this in the end, I forgot to remove
it from the code before committing. Stripping it out here. Sorry.
|
|
Spot a 'startxref' of 0 as being an error; otherwise the code
falls through and we SEGV.
Also update the pdf_repair_obj function to cope better with the new
way we parse ints. Previously we parsed ints into the buffer and
atoi'd them there - to step backwards over the int was therefore a
matter of stepping backwards over the specified number of chars.
In the 'new' code (now quite old) we parse ints directly, hence we
cannot do this stepping back. Also, stepping backwards by more than
1 byte is risky anyway. We therefore adopt a smarter approach of
returning the next lexed token from pdf_repair_obj.
Thanks to zeniko for reporting these problems and providing a test
file.
|
|
|
|
|
|
Also on first alteration create a further section to hold the updates. This
is in preparation for supporting incemental update.
|
|
Now directly read the sections handling trailers as we go, rather than
processing the most-recent trailer up front. Handle XRefStm separately
from the main section-loading loop so as to ignore Prev when it occurs
in a XRefStm (as specified in the spec). That has the side-effect of
avoiding recursion.
|
|
In multiple places, between acquiring and releasing the FREETYPE lock,
exceptions may be thrown which aren't caught in order to properly
release the lock. This patch introduces the necessary fz_try/fz_always/
fz_catch invocations to prevent a potential deadlock in these situations.
RJW: Also fix another problem pointed out by zeniko. Thanks!
|
|
Negative xstep or ysteps cause problems.
|
|
|
|
This means that warnings can now be rate limited.
|
|
|
|
Avoid all direct access to the xref table so that the impementation can
be altered to add new features
|
|
|
|
|
|
|
|
|
|
|
|
To prepare for color management, we have to make the device colorspaces
per-context and able to be overridden by users.
|
|
Found by zeniko in his fuzzing tests. Many thanks!
|
|
The PDF Reference manual is very confusing about what gstate should
be used to run patterns in.
Essentially, my experiments seem to suggest that as we run through a
PDF page, at the start of executing each stream, we should remember
the current gstate as the 'parent' gstate. Then whenever we instantiate
a pattern (via scn etc), we should set the pattern to remember that
gstate. When we come to render the pattern, the pattern should be
rendered using the remembered gstate, not the current one.
This causes many progressions in our tests.
|
|
|
|
|
|
|
|
Sometimes a PDF file can use just a very small amount of a large tile;
rendering the whole tile is a waste of time. Previous attempts to catch
this case have worked for most cases, but can be defeated when the
area needing rendering crosses a tile edge.
Here we improve the formulation to catch exactly what we want.
This implementation was driven by the example file in Sumatra PDFs
bug tracker, for issue 2248, though the actual code change is
different. Thanks to zeniko, nonetheless for this!
|
|
Ignore sign of font size when calculating X offset in vertical motion
for fonts.
|
|
Softmasks can be applied in 2 places in our code; once when starting a
group, once when running an XObject. The two implementations had
drifted apart. To avoid this in future, pull the two together.
This solves the bug, apart from the issue of transfer functions not
working.
Also, fix another issue seen in cluster testing. For luminance smasks
the bbox is only used to clip the contents drawn - the background color
extends into the surrounding area. Fix the code to respect this.
And another problem; text in soft masks would upset text outside the
SMasks - fix this by storing/restoring the text settings in the
interpreter state around the smask rendering.
|
|
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.
|
|
|
|
|
