| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Removes the need to alloc/free text strings in the API, allowing
for simple functions like pdf_dict_get_text_string.
|
|
Now handles more annotation types, and does not use the pdf-write device.
Handles many of the usual annotation properties, such as border width,
color, interior color, line ending styles.
* Ink
* Highlight, Underline, Strike-Out, Squiggly
* Line (with arrow-heads)
* Polygon
* PolyLine
* Square
* Circle
* Caret
* Text (needs better icons)
* FileAttachment (needs better icons)
* Sound (needs better icons)
* Stamp
* FreeText
Partially complete:
* Widget (treats everything like a plain text field)
Not done, but on the to-do list:
* /BS style (solid/dashed/bevel/inset/underline)
* /BS dash pattern
Not done and not on the list:
* Movie
* Screen
* Printer's Mark
* Trap Network
* Watermark
* /Border corner radii (ignored by acrobat)
* /BE cloudy border effect
|
|
|
|
|
|
|
|
|
|
|
|
Also remove useless pdf_new_null and pdf_new_bool functions.
Use the PDF_NULL, PDF_TRUE, and PDF_FALSE macros instead.
|
|
|
|
|
|
Add a PDF_NAME(Foo) macro that evaluates to a pdf_obj for /Foo.
Use the C preprocessor to create the enum values and string table
from one include file instead of using a separate code generator tool.
|
|
Use pdf_dict_put_* convenience functions.
Use pdf_dict_get instead of pdf_dict_gets with constant strings.
|
|
pdf_dict_put_dict creates a new empty dictionary, inserts it
into the parent dictionary, and returns a borrowed reference to it.
These functions should simplify document creation by removing the
need to wrap creation with try/catch for reference counting cleanup.
|
|
|
|
length.
|
|
|
|
|
|
We need both RC4 and AES encryption. RC4 is a straight reversable
stream, and our AES library knows how to encrypt as well as decrypt,
so it's "just" a matter of calling them correctly.
We therefore expose a generic "encrypt this data" routine (and a
matching "how long will the data be once encrypted" routine) within
pdf-crypt.c.
We then extend our our PDF object output routines to call these.
This is enough to get encrypted data preserved over calls to mutool
clean. Unfortunately the created files aren't readable, due to 2
further problems, also fixed here.
Firstly, mutool clean does not preserve the Encrypt entry in the
trailer. This is a simple fix.
Secondly, we are required NOT to encrypt the Encrypt entry. This
requires us to spot the crypt entry and to special case it.
|
|
Currently, our API uses static inlines for fz_lock and
fz_unlock, the definitions for which depend on whether
we build NDEBUG or not. This isn't ideal as it causes
problems when people link a release binary with a debug
lib (or vice versa).
We really want to continue to use static inlines for the
locking functions as used from MuPDF, as we hit them
hard in the keep/drop functions.
We therefore remove fz_lock/fz_unlock from the public API
entirely. Accordingly, we move the fz_lock/fz_unlock
static inlines into fitz-imp.h (an internal header),
together with the fz_keep_.../fz_drop_... functions.
We then have public fz_lock/fz_unlock functions for any
external callers to use that are free of compilications.
At the same time, to avoid another indirection, we change
from holding the locking functions as a pointer to a
struct to a struct itself.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
First, we add an fz_page_overprint function to detect if a
page uses overprint. Only PDF implements this currently (other
formats all return false). PDF looks for '/OP true' in any
ExtGState entry.
We make Mutool check this. If it finds it, and spot rendering
is not completely disabled, then it ensures that the separation
object passed to the pixmap into which we draw is non NULL. This
causes the draw device to do overprint simulation.
We ensure that mutool draw defaults to having the spot rendering
mode default to simulation in builds that support it.
Finally, we ensure that if an output intent is set by the document,
and spot rendering is not completely disabled, then we ensure the
seps object is non NULL so that we render to a group in the
specified output intent, and THEN convert down to the required
colorspace for the output.
This should make us match acrobats behaviour.
|
|
|
|
|
|
|
|
|
|
|
|
Rename fz_write to fz_write_data.
Rename fz_write_buffer_* and fz_buffer_printf to fz_append_*.
Be consistent in naming:
fz_write_* calls write to fz_output.
fz_append_* calls append to fz_buffer.
Update documentation.
|
|
|
|
|
|
Commit a92f0db5987b408bef0d9b07277c8ff2329e9ce5
introduced a typo causing pdf_sort_dict() to try to
sort non-dict objects. Attempting to do this for
non-dict objects causes a segmentation fault. For
dictionary objects this causes a performance
degradation that has not been noticed.
pdf_sort_dict() is called in two places:
pdf_dict_get_put() and showgrep().
The resson that calling pdf_sort_dict() from
pdf_dict_get_put() does not cause a segmentation fault
is that pdf_dict_get_put() makes sure that the object
is a dictionary before calling pdf_sort_dict(), which
will then decide NOT to sort the dict keys.
showgrep() on the other hand does not make sure that it
is only processing dict objects before calling
pdf_sort_dict() which caused a segmentation fault.
|
|
pdf_array_delete and pdf_dict_put_val_null weren't calling this function.
|
|
It's only used to 'fix' duff indirect references when cleaning PDF
files. Writing general values into dictionaries should be done by key,
not by internal index.
|
|
Previously, attempting to put an object beyond the end of
an array would throw an error. Here we update the code to
allow objects to be placed *exactly* at the end (i.e. to
extend the length by 1).
Update js use of pdf_array_put.
|
|
|
|
A PDF repair can be triggered 'just in time', when we encounter
a problem in the file. The idea is that this can happen without
the enclosing code being aware of it.
Thus the enclosing code may be holding 'borrowed' references
(such as those returned by pdf_dict_get()) at the time when the
repair is triggered. We are therefore at pains to ensure that
the repair does not replace any objects that exist already, so
that the calling code will not have these references unexpectedly
invalidated.
The sole exception to this is when we replace the 'Length' fields
in stream dictionaries with the actual lengths. Bug 697015 shows
exactly this situation causing a reference to become invalid.
The solution implemented here is to add an 'orphan list' to the
document, where we put these (hopefully few, small) objects. These
orphans are kept around until the document is closed.
|
|
We call Memento_addRef etc in fz_keep_impXX functions, so
don't call them in the callers too.
|
|
|
|
|
|
|
|
Only direct PDF name objects should be used as arguments,
indirect PDF name objects cannot be used.
|
|
|
|
This avoids resolving object references which is
important for dictionary keys.
|
|
|
|
|
|
The mark & sweep pass of garbage collection, and resolving indirect objects when grafting objects
was following the full chain of indirect references. In the unusual case where a numbered object
is itself only an indirect reference to another object, this intermediate numbered object would
be missed both when marking for garbage collection, and when copying objects for grafting.
Add a function to resolve only one step for these two uses.
The following is an example of a file that would break during garbage collection if we
follow full indirect reference chains:
%PDF-1.3
1 0 obj
<</Type/Catalog /Foo[2 0 R 3 0 R]>>
endobj
2 0 obj
4 0 R
endobj
3 0 obj
5 0 R
endobj
4 0 obj
<</Length 1>>
stream
A
endstream
endobj
5 0 obj
<</Length 1>>
stream
B
endstream
endobj
|
|
|
|
|
|
This stops Bug693111.pdf giving errors.
|
|
This silences the many warnings we get when building for x64
in windows.
This does not address any of the warnings we get in thirdparty
libraries - in particular harfbuzz. These look (at a quick
glance) harmless though.
|
