| Age | Commit message (Collapse) | Author |
|---|
|
Gradients in XPS code are ordered by offset. If however two offsets are
equal, the order of the colors depends on the sort algorithm instead of
the original order in the document. This is shown e.g. in 2245*.xps:
<GradientStop Offset="0" Color="#ff00ff00" />
<GradientStop Offset="0.5" Color="#ff0000ff" />
<GradientStop Offset="0.5" Color="#ff00ff00" />
<GradientStop Offset="1" Color="#ff00ffff" />
Tracking the original order of gradient stops and always sorting earlier
stops first makes gradient ordering consistent.
|
|
|
|
By default an OCG is supposed to be visible (for a testcase, see
2011 - ocg without ocgs invisible.pdf). Also, the default visibility
value can be overwritten in both ways, so that pdf_is_hidden_ocg
must check the state both for being "OFF" and "ON" (testcase was
2066 - ocg not printed.pdf rendered with event="Print").
|
|
* If fz_alpha_from_gray throws in fz_render_t3_glyph, then glyph is leaked.
* If fz_new_image throws in pdf_load_image_imp, then colorspace and mask
are leaked.
* pdf_copy_pattern_gstate overwrites font and softmask without dropping
them first.
|
|
Content streams may contain multiple inline images compressed as LZW
data. The LZW filter used for such inline images might in some cases
be closed in a state where less than 8 bits remain unread. The parent
stream remembers that number (in stream->avail) and uses it again
when reading the next inline image instead of resetting the remaining
bit count when reading the next entire byte after the first inline image
(or resetting it when closing the LZW stream as this patch does).
|
|
If /EndOfLine is set for a CCITTFaxDecode stream, the image must start
with an EOL per the spec. Other readers seem to ignore all data up to
the first EOL in that case - instead of rejecting such images as broken.
Required for e.g. "1848 - 1d faxd doesn't start with EOL.pdf".
|
|
|
|
|
|
Broken in recent optimisations.
|
|
The symptoms were that, created annoations were in some cases not saved.
Some updated objects withing the document were not being moved into the
incremental-save xref section. That in turn was due to nodes within the
hierarchy of those objects not having their parent_num field set. The
objects falling foul of this problem were those held in object streams.
When any one object from a stream is cached, the whole stream is read and
all other objects from that stream are also cached, but only the initial
one has its parent_num set. This patch ensures that all objects from a
stream are accounted for. In fact, for the initially-requested object, we
now set parent_num twice, but that is harmless and the code to avoid doing
so wouls be an unnecessary complication.
|
|
|
|
|
|
This is the single largest hotspot in J11_acrobat.pdf on the pi,
by a massive margin.
J12_acrobat.pdf hits fz_paint_affine_g2rgb too.
|
|
If we want the alternative versions we can pull them out of git
later.
|
|
The 2 biggest hotspots in benchmarking on the Raspberry pi at
1200dpi.
|
|
Forgot to drop the font.
|
|
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.
|
|
|
|
|
|
The current code uses a hash table with linear probing. This means
that when the cache fills up, we have no alternative but to bin the
whole thing (or do an expensive rebuild).
Change to using a simple hash table with linked lists of bucket chains,
and additional LRU lists. This way we can ditch the oldest glyphs as
we need more space.
|
|
Use of the feature is currently enabled only in the case that a file
that already contains xref streams is being updated incrementally. To
do so in that case is necessary because an old-style xref is then not
permitted.
This fixes bug #694527
|
|
|
|
This allows us to "mudraw -F ppm -o /dev/null" etc.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
Thanks to Tor for finding the correct definitions for me.
|
|
|
|
|
|
|
|
|
|
Images were missing a space, hence giving errors.
SVG text gets confused by leading (and repeated) whitespace, so elide it.
|
|
This bug has been in here for ages, but was masked by a bug in the
gel clipping that was fixed by Tor earlier.
|
|
pdf_js_setup_event strdups the field value, then nothing ever uses it
again.
|
|
Thanks to Pengsu Cheng for pointing out the problem.
|
|
The case with infinite scissor didn't work.
|
|
|
|
Thanks to "willus" for pointing out this problem.
|
|
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
|
