| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds a page merging tool. The tool demonstrates the
use of object grafting. The object grafting function recursively
goes through the object to add all referenced objects. A map is
maintained to ensure that objects that have already been copied are
not copied again.
|
|
The DP and BDC operators, are used in the form:
<NAME> <PROPERTIES> <OPERATOR>
where <PROPERTIES> can either be a name (that can be looked
up to get a dictionary) or an inline dictionary.
What the spec doesn't say is that the two are not
interchangeable. If you resolve the name to an inline
dict, then insert it, Acrobat will give an error for
some (but not all) cases.
The interpreter currently resolves any references, and
passes the resolved version into the operator handling
function. This precludes us outputting the original
form.
We therefore update it to pass both the raw and the cooked
versions in. This has no effect on MuPDFs own handling of
anything, it just enables the buffer device to output
a correct stream.
|
|
When sanitizing a file, while cleaning with decompression, I was
seeing a flate problem reported.
The issue is that pdf_open_filter was passing pdf_open_raw_filter
the orig_num as both num and orig_num. This was causing us to
find an fz_buffer attached to the (wrong) xref entry and to open
that instead of the underlying stream.
The fix is to propogate num a bit further.
|
|
Use pdf_dict_put_drop rather than pdf_dict_put to avoid leaking
int pdf_obj.
|
|
Remove some bonkers conditions arising (presumably) as a
result of search and replace.
|
|
|
|
Caused by a mismatch in the annotation creation/loading code.
|
|
If we rewrite a page content stream, and then drop that entire page
we shouldn't leak the buffer.
Or to put it another way, when we change the obj for an xref entry,
ditch the cached stm_buf.
|
|
It's implicit in the 'top' box.
|
|
Point to the box struct rather than its style, so we can look at its
resolved em size. Also make sure to resolve em sizes for inline boxes.
|
|
|
|
|
|
|
|
|
|
We will need to split if the color changes, or an image is spliced in.
List item bullets also get their own fz_text element.
|
|
|
|
If used, PDF objects are cleared at the end of each page, and
the store size is set to 1 byte, avoiding the caching of images.
This trades repeated decoding of images/reading of file objects
for memory usage. The purpose of this is to enable measurements to
be made on the minimum possible memory level.
|
|
|
|
|
|
|
|
Default to "ltr" (unhelpfully, but that's the spec).
Handle ltr, rtl, and auto values.
|
|
And use the same enum for both the internal bidi code and the layout code.
|
|
|
|
Either the style context shouldn't be shared, or it shouldn't be
incremented when we clone it.
Sharing it seems correct to me, but we should protect reading it
against simultaneous changes.
|
|
In certain simple circumstances, we can bypass harfbuzz shaping and gain
a lot of performance.
|
|
Remove the need for type punning, and make it behave more robustly
for indic languages.
|
|
We were setting it to zero if not building a bbox table, which caused havoc
with the advance width caching.
|
|
|
|
|
|
|
|
|
|
Also remove redundant assignments.
Fixes http://bugs.ghostscript.com/show_bug.cgi?id=695968
|
|
|
|
|
|
This avoids the displaylist device not playing back space glyphs.
|
|
In particular for html docs we were getting the refcount wrong,
causing us to leak on closedown.
|
|
If a "word" of HTML is split into several fragments by the
string walker (due to glyphs not being available in the same font)
then we'd previously have walked too much of the string when
pulling glyphs out of the harfbuzz buffer.
Only walk as much as we should.
|
|
|
|
This is stated in table 3.22 in PDF Reference 1.7.
Fixes valgrind errors for SIGABRT-090214-045131-116.pdf from bug 695040.
|
|
Combining marks were being offset in the wrong direction vertically.
|
|
|
|
|
|
|
|
|
|
Reintroduce fz_load_jpeg() (previously removed in 12c1466) improved with:
* application agnostic memory handler support from 6a8abce
* colorspace context from 93bd1ff
* resolution detection from 4dc6cbe
|
|
|
|
* Use a better 4-bit fallback palette (use vga palette as
indicated by variable name instead of 16 color web palette)
* Determine if existing palette entries are grayscale and if so
use a grayscale palette instead of the vga or web palette
* Extend the web palette with black entries to make it eaiser
to copy from.
|
|
|
|
|
|
|
