| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Update Android build for new thirdparty.zip.
Small windows fix for pdf_xref -> pdf_document changes.
|
|
This a) improves our branding, and b) avoids conflicts with
other pdf tools out there (pdfinfo etc).
|
|
|
|
Updated thirdparty.zip contains newer jpeg, jbig2 and freetype code.
|
|
|
|
This brings MuXPS up to date with GhostXPS as of today.
The commits pulled in are:
856ecdc Whitespace fixes for parsing dashed line attributes
91dc749 Whitespace fixes while parsing points.
This commit is tweaked from the original, and the
changes will be pushed back into GhostXPS shortly.
a298a05 Tiff premultiplied/non-premultiped alpha differences.
No changes required for this, as we hold images
premultiplied already (and already cope with
premultiplying where required). Some changes to
comments and cleanup code to avoid leaks though.
|
|
On extreme downscales, the weights for each pixel can all round to
zero; this results in no weights being stored at all, and causes
either an exception or a SEGV. The simple fix is to ensure that the
first pixel that's actually in range (and there will always be one)
always has a weight of at least 1.
Thanks to malc for finding the test cases that lead to this bugfix.
|
|
Thanks to Zeniko for this; one line fix in the fax decoder, to
cope with a case at the start of lines.
This fixes:
x - 1d faxd overflow.pdf
and
x - 1d faxd negative code.pdf
|
|
This was causing a SEGV in cluster testing of Bug690724.pdf.
|
|
fz_draw_fill_image_mask was improperly nesting group start/ends, by
calling fz_knockout_start at the top, and then fz_knockout_start
again at the end. Changing this latter one to fz_knockout_end
solves the problem.
Also tweak the debugging code slightly to give more readable results.
|
|
The cluster testing of MuPDF repeatedly crashes on
pdf/PDF_1.7_FTS/fts_20_2008.pdf. Investigation shows this is because
we fail to write the newly allocated mask back to the graphics
state stack when starting a clip_stroke_text drawing operation.
This causes later pops to fall over.
Simple fix.
|
|
All destructors should accept NULL.
|
|
Modified version of Sumatras patch. Thanks for this.
|
|
The ARM optimised code relied on the size of the weights structure
which was changed by the addition of a new member as part of the
patch scaling changes. Fix the code here, and add a note to the
structure in the hopes that this will avoid such breakages happening
in future.
|
|
Both Zeniko and Malc have said that this causes problems.
Following a hint from malc, the following command causes the
assert to trigger:
win32/Debug/pdfdraw.exe -r0.3 -o out.png ../MyTests/pdf_reference17.pdf 1143
I suspect it's because of the extreme resolution, and the round_rect
call. At any rate, disabling the assert is of no real import.
|
|
Thanks for filmor for identifying this.
|
|
|
|
|
|
When scaling a bitmap, currently we always scale the entire bitmap,
even if we only need a small section of the result.
This patch changes the code to take an optional 'clip' bbox, and
only scales as many pixels as are required to generate the required
output region.
|
|
|
|
This way both pixmaps for rendering and image data are top-down.
|
|
Just mirror the changes done in pdfdraw.
|
|
Thanks to filmor's help, fix some problems where locking was going
wrong; in 2 cases we failed to unlock, and in 2 cases we tried to
free (which relocks) while already locked.
All simple fixes.
|
|
This reverts commit 08e84b18e5c1dbe8f3d32dd0aeb4b4c43debce9f.
|
|
|
|
|
|
Require that clients call pdf_needs_password/pdf_authenticate_password
instead. For dumb clients, we still allow for decrypting a file with
a blank password without calling those functions.
|
|
When scaling a bitmap, currently we always scale the entire bitmap,
even if we only need a small section of the result.
This patch changes the code to take an optional 'clip' bbox, and
only scales as much of the input as as required for this output
region.
|
|
When we moved over to a context based system, we laid the foundation
for a thread-safe mupdf. This commit should complete that process.
Firstly, fz_clone_context is properly implemented so that it
makes a new context, but shares certain sections (currently
just the allocator, and the store).
Secondly, we add locking (to parts of the code that have
previously just had placeholder LOCK/UNLOCK comments). Functions
to lock and unlock a mutex are added to the allocator structure;
omit these (as is the case today) and no multithreading is
(safely) possible. The context will refuse to clone if these are
not provided.
Finally we flesh out the LOCK/UNLOCK comments to be real calls of
the functions - unfortunately this requires us to plumb fz_context
into the fz_keep_storable function (and all the fz_keep_xxx
functions that call it). This is the largest section of the patch.
No changes expected to any test files.
|
|
Some Type 3 fonts contain glyphs that rely on inheriting various
aspects of the graphics state from their calling code. (i.e. a
glyph might use d0, then fill an area without setting a color
first).
While the spec is vague on this point, we believe that technically
it is invalid. Previously mupdf defaulted all elements of the graphic
state back when beginning to draw the glyph. This does not match
what Acrobat does though, so we change the approach taken.
We now watch (by use of bits in the device flags word) for the use
of parts of the graphics state before it is set. If such use is
detected, then we note that the glyph is 'uncacheable' and render
it direct.
This seems to match Acrobats behaviour.
|
|
Toggle with 'f'. Fullscreen turns off shrinkwrap, and shrinkwrap turns
off fullscreen.
|
|
Automatically skip segments in a path that serve no
purpose at construction time.
* MOVE then MOVE -> the original MOVE is ignored.
* LINETO the currentpoint -> ignored if previous segment was
not a moveto.
* CURVETO the currentpoint (with coincident coords) -> ignored
if previous segment was not a moveto.
* CLOSE then CLOSE -> second close ignored.
It's worth noting here that in pdf a closepath leaves the
current point at the point which it closes to - any new
segments will begin a new subpath, but the current point
is defined.
|
|
pdf_resolve_indirect(x) = pdf_resolve_indirect(pdf_resolve_indirect(x))
now - as long as it doesn't throw an exception.
Update the rest of the code to minimise unnecessary function calls.
Previously, we were calling one function to find out if an object was
a dict, only for that to call a function to see if it needed to
resolve the object, then calling another function to actually get the
dict, only to have that call the function to check for the dict
needing resolving again!
|
|
Every xobject keeps a reference to the object from whence
it came. This is marked/unmarked as it is executed.
Thanks to Zeniko for spotting the potential problem.
|
|
Copes with files with many many gstates in; such as 'tikz-gtree'
documents, according to Sumatra.
Thanks to Zeniko for this.
|
|
Thanks to Zeniko for this.
|
|
Thanks to Zeniko for spotting these problems.
|
|
Thanks to Zeniko for spotting the problem here.
|
|
Ensure we don't get a division by zero (when *phase goes to 16).
Also ensure we don't overflow the bounds of an unsigned int.
Thanks to Zeniko for spotting these problems.
|
|
The call to opj_set_event_mgr would overwrite client_data=ctx
with client_data=stderr - not what was wanted.
Thanks to Zeniko for this.
|
|
XPS differs from PS/PDF/etc in the way it handles miters; rather than
simply converting a miter that's overly long to a bevel, it truncates
it at the miter limit. As such it needs to be handled correctly.
For clarity, expose new enumerated types for linejoins and linecaps,
and use these throughout code.
When we upgrade our freetype, we can move to using proper xps mitering
in that too.
Add new fz_matrix_max_expansion function to return a safer expansion
value that works in the case where we scale up in one direction and
down in another.
In the xps path drawing code, avoid generating unnecessary linetos.
Thanks to Zeniko for spotting these and providing implementations.
|
|
Check for cid being in range before using it. Thanks to Zeniko for
spotting this.
|
|
|
|
|
|
|
|
|
