| Age | Commit message (Collapse) | Author |
|---|
|
It is vital that no one returns from within fz_try. As such it's often
necessary to jump out of an fz_try. This can mean using a label at the
end of the fz_try section to goto.
By introducing a "do { } while (0)" around the contents of the fz_try
we allow people to 'break' (or 'continue') to get out neatly.
|
|
This frees us from passing errors back everywhere, and hence enables us
to pass results back as return values.
Rather than having to explicitly check for errors everywhere and bubble
them, we now allow exception handling to do the work for us; the
downside to this is that we no longer emit as much debugging information
as we did before (though this could be put back in). For now, the
debugging information we have lost has been retained in comments
with 'RJW:' at the start.
This code needs fuller testing, but is being committed as a work in
progress.
|
|
|
|
|
|
|
|
|
|
Huge pervasive change to lots of files, adding a context for exception
handling and allocation.
In time we'll move more statics into there.
Also fix some for(i = 0; i < function(...); i++) calls.
|
|
Import exception handling code from WSS, modified to fit into the
fitz world.
With this code we have 'real' fz_try/fz_catch/fz_rethrow functions,
handling a fz_except type. We therefore rename the existing fz_throw/
fz_catch/fz_rethrow to be fz_error_make/fz_error_handle/fz_error_note.
We don't actually use fz_try/fz_catch/fz_rethrow yet...
|
|
|
|
Also don't read out of bounds if the string is cut short in the
middle of the last two-byte character.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Make sure the CSI works from a clean slate in pdf_run_stream, since it
may be called to draw a softmask form pdf_flush_text in the middle of
parsing a TJ text array.
Also guard against xobject failures by catching instead of rethrowing
xobject parse errors so that the begin and end group draw calls are
balanced.
|
|
|
|
Fix bug 692282.
|
|
Fix bug 692325.
|
|
Detect the d0 or d1 operators by writing a bit to the new device
flags word. This can then be checked by the Type3 code to create
the appropriate backing pixmap.
In order to know what the appropriate backing pixmap is, we pass
an additional colorspace into the glyph rendering code.
|
|
Not quite sure how this one slipped through - must add encrypted documents
to the mupdf test suite.
|
|
Firstly, this takes on some of Zenikos patch to correct the clip
stack handling that was broken by the fix to bug 692287 (in commit
2c3bbbf). This bug should now be solved.
We add a new 'shape' field to the draw device structure (and clip
stack). When we are inside non-isolated groups, this is set to be
a pixmap where we accumulate the 'shape' of the objects drawn.
When we come to blend back, if we are blending a non-isolated group
back, we have to use a different blending function that takes account
of the shape.
Various internal groups (the page group, and groups used to force
blending) are set to be isolated to avoid carrying shape planes
around when this is not required.
All our rendering code now has to know how to maintain the shape
plane as well as doing the basic rendering.
|
|
First, we add clipping rects to clipping functions. Various functions
(the ones that handle clipping) are now additionally passed a rectangle
that represents an additional bound for this clip in device space
(i.e. it has already been mapped through the current ctm).
Next, when constructing the displaylist, keep track of the bounding box
for the contents of each clip.
While writing the list, on every node we add, we add the bbox for that
node to the enclosing clips content bbox (if there is an enclosing clip).
When we pop a clip, write back to the corresponding push to update
the bbox.
This means if we get large clip regions, with only small areas used within
them, we will only do the slow blending for those small areas.
Finally, we fix a calculation in fz_bound_path which was incorrectly
accounting for mitrelimits. This was showing up in testing on page 630
of the PDF reference v1.7.
|
|
In the existing mupdf clip path code, it would be possible for us to
render incorrectly; consider the following fragment of a content
stream:
0 0 100 100 re
W
50 50 100 100 re
f
That should set the clip path to the (0, 0) -> (100, 100) rectangle,
and then attempt to fill both the (0,0) -> (100,100) rectangle and the
(50,50) -> (150,150) rectangle, resulting in just the (0,0) -> (100,100)
rectangle being filled.
In the existing mupdf code, it would actually fill both rectangles as
the path after the W operation (the addition of the second rectangle)
would also affect the stored clip path.
We solve this by doing the clip operation on the W operator, rather than
deferred to when the path is actually disposed of.
|
|
Acrobat (and gs, see bug 690478) will open a file without a CF dictionary
by assuming that the encryption type is RC4. Mirror this in mupdf.
|
|
Bring the MuPDF android build up to date with the latest source changes.
Many thanks to Dominic Battre for his helpful report in bug 692222.
|
|
Bug 692245 gives a file that produces a runtime assert in mupdf due to an
extremely large ctm offset (unrepresentable in a float). We fix our code
here so that such floats are always read as 1.0.
In this particular case, the exact value read doesn't seem to matter. We
match acrobat. We pick 1.0 rather than 0.0 as this is less likely to
provoke division by 0 errors later on.
|
|
Some particularly broken generators forget to terminate the
comment with a newline. Skip the comment character so we'll
get some garbage tokens that we can ignore, rather than
consuming the innocent objects that follow on the same line
as the %.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The file in question is missing newlines, causing the first two
objects to be hidden because we treat the %PDF-1.3 version marker
as a comment.
|
|
|
|
|
|
This bug fix shaves another 650K off the compiled in cmaps!
Also fix the detection for when the cmap table is full, and ignore
surrogate pair mappings (since we can't do anything useful with
them at the moment).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All image loading functions call the new fz_new_pixmap_with_limit
allocation function, which will return NULL if the total amount of
pixmap memory would exceed a set limit. Other vital pixmap allocations
which are not as easily recoverable (such as font rendering, and the
various buffers in the draw device) ignore the limit.
|
