| Age | Commit message (Collapse) | Author |
|---|
|
Don't create a useless pdf_font_desc when writing font resources.
Simplify reference counting by using fewer intermediate variables.
|
|
Use KOI8-U for Cyrillic, and ISO 8859-7 for Greek.
Use with 'mutool create' using an extra argument to the %%Font directive:
%%Font TmRmC Times-Roman Cyrillic
BT
/TmRmC 16 Tf 10 10 Td
<fa c4 d2 c1 d7 d3 d4 d7 d5 ca d4 c5 21> Tj
ET
The alternatives are "Latin", "Greek", and "Cyrillic".
|
|
Create a non-embedded CJK font using UTF-16 encoding. This can be used
in mutool create like so:
%%CJKFont Ming GB1
BT
/Ming 10 Tf
100 100 Td
<4F60 597D> Tj
ET
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Just use the pdf_obj directly.
Revise ap_iteration and split annot->dirty into separate flags.
One flag for needs_new_ap, and one for has_new_ap (to be used by
clients who may have cached a rendered annotation).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the absence of C99 (fz_rect){0,0,1,1} syntax, this will have to do.
|
|
Avoids the silliness of fz_annot_type pdf_annot_type().
|
|
|
|
Call these from the PDF interpreter. Make the DisplayList and
Trace devices cope.
Use these in the SVG output device.
|
|
|
|
Use a FZ_PRINTFLIKE macro instead.
|
|
|
|
|
|
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.
|
|
This is needed to simplify the way the bytes for hashing are
passed to pkcs7 functions.
|
|
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.
|
|
Previously, errors were reported with a boolean function return
with a char buffer filled out with the reason in the failure
case. Now an enum is used to report the various failure cases.
The function pdf_check_signature has been left as is so that
existing apps will not need changing.
|
|
|
|
|
|
|
|
|
|
Previously, signature verification worked only for file-based documents
and the file path had to be passed into the verification function.
|
|
This change achieves two goals. It allows signing to be performed even
when the document is obtained other than from a disk file. It also
reestablishes to a working state signing of file-based documents, a feature
that was broken due to complete_signatures being called after certain
tables, avaialble via the output options object, had been destroyed.
|
|
This provides a way for some output streams to also be read, a feature
needed for the sake of document signing. Currently this is supported only
for file output.
|
|
|
|
Once a stream has thrown an exception or reached EOF,
don't allow further reading.
The EOF flag is reset when fz_seek is invoked.
|
|
|
|
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.
|
|
|
|
This is true because they are now limited below PDF_MAX_OBJECT_NUMBER.
|
|
|
|
This ensures that:
* xref tables with objects pointers do not grow out of bounds.
* other readers, e.g. Adobe Acrobat can parse PDFs written by mupdf.
|
|
This needs adding a fz_xml_doc type to hold the pool.
|
|
This goes well with the 'mutool clean -d' decompression option to debug
content streams, without doing the sanitize optimization pass.
|
|
|
