| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Filter out Link and Popup annotations.
Links are not comments, popup annotations are auxiliary information
for other annotations, so neither of these types should be present
in our list of annotations, but all other annotations should be there,
whether they have appearance streams or not.
Ensure has_new_ap is zero when first loaded, and changed if either
the active AP object is changed or the current AP content stream
is updated.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add a version of pdf_check_signature function that reports no support,
for builds without openssl. This allows the removal of ifdefs from the
apps.
|
|
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.
|
|
|
|
The bug reports a buffer overflow, but after that was fixed this leak
was reported by ASAN.
|
|
Opening in append mode was used before commit
c4d3a9142761a567fce9f66946a917e087c0de67
when the same file was reopened multiple times for formats that
support it. Nowadays the files is only opened once anyway so there
is no reason to use append mode.
|
|
Previously, signature verification worked only for file-based documents
and the file path had to be passed into the verification function.
|
|
|
|
|
|
This goes well with the 'mutool clean -d' decompression option to debug
content streams, without doing the sanitize optimization pass.
|
|
|
|
Also clarify that a copy of author/contents is returned, and that
the caller must free them.
|
|
This mirrors the existing PDFObject.asByteString().
|
|
|
|
|
|
Previously when metadata was not found mupdf still tried
to return a string to the caller, but the string was uninitialized.
|
|
This way the MuPDF library itself only uses fz_snprintf for
consistent formatting.
|
|
|
|
|
|
This affects the given character bboxes.
|
|
If nothing else, this avoids warnings on VS2005.
|
|
Also, fix mudraw messages about what types can be banded.
|
|
Any pixmap writers that can handle data with an alpha plane
should accept that data in premultiplied form, and write it out
appropriately for the file format.
This avoids the need to unpremultiply data in mudraw, and solves
the issue we were seeing where we want the png writer to be able
to cope with premultiplied data (such as for the debug blending
routines) and unpremultiplied data (such as that given after
mudraw has unpremultiplied the data).
|
|
|
|
Closing flushes output and may throw exceptions.
Dropping frees the state and never throws exceptions.
|
|
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.
|
|
Running Ghent_V5.0/GWG010_CMYK_OP_x3.pdf to PNG produces
'X' marks, where Acrobat does not. This is expected if
overprint similation is turned off, but not if it is
enabled.
The file does not define a colorspace for the initial page,
uses no transparency, and has no spots defined. Accordingly,
when we clone the page fz_separation object, we end up with
no object at all. The draw device therefore doesn't even
attempt to do overprint simulation.
We fix this by ensuring that we always have a non-NULL
separation object. Possibly we should make fz_page_separations
return a non-NULL, but empty object?
Even with this change, running to PNG still does not give the
required rendering. This is because PNGs use RGB, rather than
CMYK, and overprint is disabled for non-subtractive spaces.
We therefore adjust the code in push_group_for_separations
that decides whether it can avoid pushing an extra group.
If the basic pixmap is RGB, then we never skip the extra
group.
|
|
This is a first cut to get us to demo-ability. There will
likely be a few changes as we do a bit more testing with different
scenarios with Gray, RGB, CMYK combos of destination, proof and
output intent ICC profiles.
|
|
|
|
Both bandwriter and document_writer interfaces cope with multi
page docs.
Update mudraw to output pclm format too.
Incorporates fixes from Tor.
|
|
|
|
Avoid double freeing the device colorspaces.
|
|
|
|
The code only worked for string literals, not garbage collected or
short strings.
|
|
|
|
|
|
|
|
|
