| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Previously there was a bug when parsing GoToR link annotations that had
a named destination. mupdf incorrectly attempted to resolve the
destination in the current document. Now the destination name is
present in the link objects returned to the application so it can
resolve any names for GoToR links in the remote document instead.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
