Age | Commit message (Collapse) | Author |
|
Use separate functions to keep the code simpler.
Use memmem to simplify and optimize search for 'endstream' token.
Do not look for 'endobj' since that could cause a false positives in
compressed object streams that have duff lengths.
|
|
|
|
|
|
When a document is signed multiple times, an incremental update is needed
for each, the multiple updates sometimes written to the file as a single
saving operation. Within pdf_sign_signature it is the call to
pdf_signature_set_value that marks the current section of the xref to which
changes are recorded as "full", so that subsequent changes will trigger the
creation of a new section. Within pdf_sign_signature we were creating the
signature's appearance stream after the call to pdf_signature_set_value and
hence triggering an extra unnecessary setction. This commit moves the
pdf_signature_set_value to after the creation of the appearance stream, so
that we need only as many new xref sections as there are signings.
|
|
Several things irk me about passing values as const pointers:
* They can be NULL, which is not a valid value.
* They require explicit temporary variables for storage.
* They don't compose easily in a legible manner, requiring
weird pointer passing semantics where the variable being assigned
is hidden as an argument in the innermost function call.
* We can't change the value through the pointer, requiring yet more
local variables to hold copies of the input value.
In the device interface where we pass a matrix to a function, we often
find ourselves making a local copy of the matrix so we can concatenate
other transforms to it. This copying is a lot of unnecessary busywork
that I hope to eventually avoid by laying the groundwork with this
commit.
This is a rather large API change, so I apologize for the inconvenience,
but I hope the end result and gain in legibility will be worth the pain.
|
|
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
|
|
|
|
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.
|
|
The mupdf build included an implimentation of the pkcs7 functions that
are needed for signing documents and verifying signatures, the
implementation being either an openssl-based one, or a stub that returned
errors. This commit removes the pkcs7 functions from the main mupdf
library.
For the sake of verification, there wasn't really a need for the pkcs7
functions to be part of mupdf. It was only the checking function that used
them. The checking function is now provided as a helper, outside of the
main build. The openssl-based pkcs7 functions area also supplied as a
helper. Users wishing to verify signatures can either use the checking
function directly, or use the source on which to base their own.
Document signing requires more integration between mupdf and pkcs7
because part of the process is performed at time of signing and part when
saving the document. Mupdf already had a pdf_pkcs7_signer object that
kept information between the two phases. That object has now been extended
to include the pkcs7 functions involved in signing, and the signing
function now requires such an object, rather than a file path to a
certificate. The openssl-based pkcs7 helper provides a function that, given
the path to a certificate, will return a pdf_pkcs7_signer object.
The intention is that different implementations can be produced for
different platforms, based on cryptographic routines built into the
operationg system. In each case, for the sake of document signing, the
routines would be wrapped up as a pdf_pkcs7_signer object.
|
|
|
|
Rather than provide a stream and an explicitly defined set of byte ranges
within that stream, provide a stream that gives access to just the bytes in
the ranges.
|
|
Previously, pdf-pkcs7.c contained mishmash of functions required
for creating and checking signatures, with no separation between
the parts relating to pdf and those relating to pkcs7. This
commit introduces pdf_signature.c which contains the pdf
specifics, leaving pdf-pkcs7.c to be purely pkcs7 functions.
This should more easily allow the use of pkcs7 solutions other
than openssl. The pkcs7 api is declared in pdf-pkcs7.h. It is
entirely free of mupdf specifics, other than using an fz_stream
to specify the bytes to be hashed.
|