| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
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.
|
|
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.
|
|
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!
|
|
Thanks to Zeniko for spotting these problems.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I don't remember exactly why I added it; but there are several
progressions when I remove it.
|
|
Keep the fuzz in just one place. Hopefully will be rendered
unnecessary by changes to make fz_bound_text accurate.
|
|
Inspired by Sumatras gdi devices need for such a function expose
the blending functions. Note that we produce unsigned char's
where Zenikos original produces ints, but it's otherwise
identical.
This requires us to make various knockon changes throughout the code
from int to unsigned char, none of which should make any difference
at all - I hope!
We reserve the right to change/amend this function in future to
operate on blocks of pixels (or pixels in different colorspaces)
(or anything else we think of) in future.
|
|
|
|
Add explanations of how to use the macros in fitz.h.
Also included are 2 different formulations, with different strengths/
weaknesses for reference. Will remove these shortly, but I want a
reference to them in git.
Workaround bug in Mac OS Lion gcc (clang works fine).
|
|
Thanks to Zeniko for pointing this out.
|
|
Add missing newline and remove excessive arguments.
|
|
Include android headers in fitz.h so we can debug.
Arrange for error throwing to output to android error stream as
well as stderr.
Change jpeg library to not use backing store. Solves bug 692473.
|
|
Various fixes to avoid overflow problems, division by zeros, use
of uninitialised variables etc. All from/suggested by Zenikos patch.
|
|
Thanks to Zeniko for pointing this out.
|
|
In error cases, ensure we free objects correctly. Thanks to Zeniko
for finding the problems (and many of the solutions!)
|
|
In various places in the code, we add markers (".seen") to
dictionaries as we traverse them to ensure that we don't
go into infinite loops.
Adding a dictionary entry is bad as it's a) an expensive
operation, b) a potentially destructive one, and c) produces another
possible point of failure (as mallocs can fail).
Instead, add a flag to each dict to allow them to be marked/unmarked
and use that instead.
Thanks to Zeniko for pointing out various places that could usefully
be protected against infinite recursion.
|
|
Externalise free_link_dest, use it in doc_outline.c to avoid a memory
leak.
Thanks to again to Zeniko for pointing this out.
|
|
A new 'cookie' parameter is added to page rendering/interpretation
functions. Supply this as NULL to get existing behaviour.
If you supply a non-NULL cookie, then this is taken as a pointer to
a struct that can be used for simple, non-thread locked communication
between caller and library.
The entire struct should be memset to zero before entry, except for
specific flags (thus coping with future extensions to this struct).
The abort flag should be zero on entry. It will be checked periodically
by the library - if the caller sets it non-zero (via another thread)
then the current operation will be aborted. No guarantees are given as
to how often this will be checked, or how fast it will be responded to.
The progress_max field will be set to an integer (-1 for unknown)
representing the number of 'things' to do. The progress field will
count up from 0 to this number as time goes by. No guarantees are
made as to the accuracy of this information, but it should be
useful for offering some sort of progress bar etc. Note that
progress_max may increase during the job.
In general, callers should be careful to accept out of range or
invalid data in this structure as this is deliberately
accessed 'unlocked'.
|
|
Fix a 'TODO'. When asking for the bounds of a shading, simply
convert the shadings bbox and intersect with that.
|
|
Move 'kind' into the fz_link_dest structure (as this makes more sense).
Put an fz_link_dest rather than just a page number into the outlines
structure.
Correct parsing of actions and dests from pdf outlines.
|
|
|
|
Move to a non-pdf specific type for links. PDF specific parsing is
done in pdf_annots.c as before, but the essential type (and handling
functions for that type) are in a new file fitz/base_link.c.
The new type is more expressive than before; specifically all the
possible PDF modes are expressable in it. Hopefully this should
allow XPS links to be represented too.
|
|
|
|
|
|
One of the previous memsqueezing fixes (specifically that in
close_dctd) appears to cause the Memento fork bases squeezing
process to stop.
This appears to be because old code would do a NULL dereference
causing a SEGV. This would somehow NOT be picked up by the signal
handler, and the child would exit.
If the code is fixed to avoid the SEGV the code then somehow
goes on to do something (not in the close_dctd code) that makes
the mem squeeze process grind to a halt - but NOT in the same
instance of the executable. I am at a loss to explain this, but
would rather the code stays as it is (being as far as I can see
correct) for now.
|
|
|
|
Disabled for now by default.
Better SEGV handling under windows (to facilitate scripted squeezing)
|
|
|
|
|
|
|
|
Rather than passing a stream to a close function, just pass context
and state - that's all that is required. This enables us to
call close to cleanup neatly if the stream fails to allocate.
|
|
|
