| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
We should use the leading, if present, and if not present we should
probably use a value a little greater than the sum of the ascender
and descender, but this is definitely a step in the right direction
and improves the look of filled-in forms.
|
|
|
|
|
|
|
|
|
|
Prevously the true bounds of the glyph were used which didn't account
for the total area blocked out by a character
|
|
This initial commit doesn't entirely complete the task:
1) There are a couple of ucs<->winansi conversions left out,
2) The text displayed by the appearance string can slightly
overflow the annotation rectangle.
|
|
Ensure that only base14 fonts are used
Set BaseFont using the name from the font
Use WinAnsiEncoding
Derive the font size from the trm matrix
|
|
|
|
|
|
pdf_js_setup_event strdups the field value, then nothing ever uses it
again.
|
|
|
|
We are testing this using a new -p flag to mupdf that sets a bitrate at
which data will appear to arrive progressively as time goes on. For
example:
mupdf -p 102400 pdf_reference17.pdf
Details of the scheme used here are presented in docs/progressive.txt
|
|
|
|
Also handle exceptions when parsing link destinations.
|
|
|
|
|
|
Instead of just relying on a depth count (which can easily be fooled
by poor but valid files) use mark/unmark based schemes for
pdf_lookup_inherited_page_item and pdf_lookup_page_number.
|
|
|
|
No more caching a flattened page tree in doc->page_objs/refs.
No more flattening of page resources, rotation and boxes.
Smart page number lookup by following Parent links.
Naive implementation of insert and delet page that doesn't rebalance the trees.
Requires existing page tree to hook into, cannot be used to create a page tree
from scratch.
|
|
|
|
Annotations can sometimes not have appearance streams (such as
Links). Avoid spewing messages to the console about this. Also
avoids overhead of throw/catch each time.
|
|
|
|
|
|
When moving an object from one xref to a new xref, ensure firstly
that we only drop each object once (by setting it to NULL) and
secondly that it has the correct parent pointer.
|
|
Thanks to zeniko for spotting the problem here.
Type 3 fonts contain a reference to the resources objects required
to render the glyphs. Traditionally these have been freed when the
font is freed. Unfortunately, after recent changes, freeing a PDF
object requires the pdf_document concerned to still exist.
While in most cases the type 3 resources are not used after we have
converted the type3 glyphs to display lists, this is not always the
case. For uncachable Type 3 glyphs (such as those that do not
completely define elements in the graphics state that they use, such
as color or line width), we end up running the glyphs at interpretation
time.
[ Interpretation time = when doing a direct render on the main thread,
or when creating a display list - so also on the main thread. No
multi-threading issues with file access here. ]
The fix implemented here is for each pdf document to keep a list of
the type3 fonts it has created, and to 'decouple' them from the
document when the document is destroyed. The sole effect of this
decoupling is to remove the resources (and the PDF operator buffers)
from the font. These are only ever used during interpretation, and
no further interpretations are possible without the document being
alive anyway, so this should have no net effect on operation, other
than allowing cleanup to proceed cleanly later on.
|
|
Make pdf_specifics callable with a NULL doc, as was fz_interact, which
it replaces.
|
|
Also add index argument to array_insert.
|
|
|
|
|
|
Correct the naming scheme for pdf_obj_xxx functions.
|
|
Thanks to zeniko for spotting these problems.
When we close a document, purge the glyph cache to ensure that
no type3 glyphs hang around with pointers to pdf_obj's that
are now gone.
Pass doc to pdf_new_obj_from_str rather than NULL. We believe
that the reason this needed to be NULL is no longer valid.
Also, revert to using an int for ref counts.
In a quick test of our regression suite we only found 2 files
that ever made a refcount > 256 (and they never got larger than
768), but the potential is there for issues. Reverting to an
int until we can think of a better idea.
|
|
|
|
|
|
Before we render a page we need to evaluate whether we need
transparency or not. To establish this, we recursively walk the
resources looking for certain markers (blend modes, alpha levels,
smasks etc). To avoid doing this repeatedly we'd like to stash
the results somewhere.
Currently we write a '.useBM' entry into the top level dictionary
object, but with the recent changes to support incremental update
this is not ideal - it has the effect of forcing all resources
into the new section of the xref.
So we avoid that horrible hack and use a different one; we make use
of the new flags word in the pdf_obj structure. 1 bit is used to
indicate whether we have stashed a (boolean) value here, and another
bit is used to indicate what that value was.
|
|
Never allow a new xref_section to be smaller than a previous
one, as this makes pdf_xref_len(xref) get unexpectedly
smaller.
|
|
|
|
For historical reasons lots of the code uses "xref" when talking about
a pdf document. Now pdf_xref is a separate type this has become
confusing, so replace 'xref' with 'doc' for clarity.
|
|
Remove the fz_context field to avoid the structure growing.
|
|
'marked' moves into the flags word. 'kind' becomes an unsigned char.
'sorted' moves from in the dictionary specific bit of the object into
the flags word. This should shrink us by 8 bytes.
|
|
When incremental update is in place, functions that alter one structure may
have the side-effect of altering another: i.e., updating an annotation may
require the Annots array or even the page to be cloned. This commit makes
the existing annotation code hardy to this eventuallity. It also cleans up
a slight mess of the past where not all annotation-altering functions had
access to the pdf_annot struture, instead having to work with just the
pdf object.
|
|
* at one place, code returns from inside an fz_try which borks up the
error stack
* pdf_load_xref wrongly assumes that at least one non-empty xref has
been read if there were no errors thrown during parsing
* pdf_repair_xref skips integers when object numbers are out of range
|
|
|
|
|
