| Age | Commit message (Collapse) | Author |
|---|
|
In the incremental case, we should update ofs_list only when actually
writing an object to file.
This is work towards bug #696123.
|
|
This is work towards supporting several levels of incremental xref,
which in turn, is work towards bug #696123. When several levels of
incremental xref are present there can be objects that appear at
multiple levels and differ between those levels. This deep-copy function
will be used to create new copies before the new version is altered.
|
|
This is work towards bug #696123. It does not fix the bug because, in fact,
saving multiple signatures in one go is not permitted (they need to use
several incremental saves), but we may as well have the order correctly
held.
|
|
These headers are already included by mupdf/fitz/system.h.
|
|
|
|
When attempting to load pdf objects and a valid pdf object is found but
it has the wrong number, mark the xref object entry as being free before
attempting to repair the xref. This ensures that if the wanted object
cannot be found in the document then the missing object will be
considered to be null. Previously it was still assumed to be around, but
the object pointer was NULL triggering an assert in pdf_load_object().
|
|
Previously these operators accepted out of range values which
triggered asserts in the rendering code.
|
|
When parsing dicts or arrays while reparing objects the xref should not
be used to try to resolve indirect objects since the xref has not been
fully rebuilt yet. As was the case prior to commit 07dd854.
|
|
Commit f533104 introduced optimized handling of pdf names, null, true
and false. That commit handles most object types correctly in
pdf_objcmp() but it does not correctly handle comparisons such as
pdf_objcmp("/Crypt", "true") or pdf_objcmp("null", "/Crypt").
Fixes one issue from bug 696012.
|
|
Previously encoding differences were allowed outside the valid unicode
codepoint range.
Fixes one issue from bug 696012.
|
|
Ensure that subsampling and caching happen in the generic image
code, not in the specific.
Previously, the subsampling happened only for images that were
decoded from streams. Images that were loaded direct were never
subsampled and hence were always cached at full size. After this
change both classes of image are correctly subsampled, and
the subsampled version kept in the cache.
This produces various image diffs in the cluster, none of which
are noticable to the naked eye.
|
|
Previously, we had people calling image->get_pixmap directly. Now we
have them all call fz_image_get_pixmap, which will look for a cached
version in the store, and only call get_pixmap if required.
Previously fz_image_get_pixmap used to look for the cached version
in the store, and decode if not - hence the decoding code is now
extracted out into standard_image_get_pixmap.
This was the original intent of the code, it just somehow didn't end
up like that.
This nicely queues us up for being able to have fz_images that use
a different get_pixel implementation, such as that which will be
required for the gprf code.
|
|
We were allocating the ofs array as ints and then filling it
with fz_off_t's.
|
|
When replacing the xref_index, lose the old one.
|
|
I'd missed converting some int's to fz_off_t's.
|
|
Fir typo in pdf_dict_del. Issue and fix both provided by Willus
(William Menninger).
|
|
When doing pdf_dict_put, we first call pdf_dict_find to hunt for an
existing entry we can just update.
Recently we introduced a 'location' return from pdf_dict_find that
would (in the non-found case) return the location of where such an
entry should be inserted.
It's just dawned on me that we don't need a separate variable for
this. We continue to return negative numbers for 'not found', but
these negative numbers can contain the insertion point.
|
|
Sebras and Tor spotted that we could get occasional 'warning: cannot seek
backwards' messages. An example command that shows this is:
mutool show pdf_reference17.pdf grep
They further tracked the problem down to the 'sorted' side of the
pdf_dict_find function.
In the binary search, I calculate c to be the comparison value between
pairs of keys. In the case where both keys (names) are in the special
case 'known' range below PDF_OBJ__LIMIT, I use pointer arithmetic for
this. Unfortunately, I was forgetting that the compiler thinks that
pdf_obj *'s are 4 (or 8) bytes in size, so was doing (a-b)/4.
To workaround this I cast both keys to char *'s. This solves the bug.
Thanks to Sebras and Tor for doing the hard work in tracking this down.
|
|
If FZ_LARGEFILE is defined when building, MuPDF uses 64bit offsets
for files; this allows us to open streams larger than 2Gig.
The downsides to this are that:
* The xref entries are larger.
* All PDF ints are held as 64bit things rather than 32bit things
(to cope with /Prev entries, hint stream offsets etc).
* All file positions are stored as 64bits rather than 32.
The implementation works by detecting FZ_LARGEFILE. Some #ifdeffery
in fitz/system.h sets fz_off_t to either int or int64_t as appropriate,
and sets defines for fz_fopen, fz_fseek, fz_ftell etc as required.
These call the fseeko64 etc functions on linux (and so define
_LARGEFILE64_SOURCE) and the explicit 64bit functions on windows.
|
|
|
|
|
|
Add fz_has_permission function to fz_document.
Add fz_lookup_metadata function to fz_document.
Remove fz_meta function from fz_document.
|
|
The new pdfclean sanitize functionality mean that mutool now
needs the data files, so maintaining the split that was designed to
keep data files out of mutool is no longer viable.
|
|
|
|
Michael needs to be able to call pdfclean from gsview. At the moment
he's having to do this by including the pdfclean.c file into the lib
build, and then calling pdfclean_main with a faked up command line.
This isn't nice.
pdfclean.c is implemented by pdfclean_main parsing the options/filenames
out of argv and then passing the filenames/options on to a
pdfclean_clean function.
This seems like a much nicer API to offer to the world.
We therefore pull the guts of pdfclean.c (pdfclean_clean and its
subsidiary structures/functions) into pdf-clean-file.c and include
this in the library build.
This leaves pdfclean.c just as the command line parsing.
This should not affect the size of any of the resulting binaries.
|
|
They hadn't been updated with recent changes. Extract the pdf page
creation code from pdf_load_page into a new static function,
pdf_new_page, and use that from both places.
|
|
When writing a pdf page, we pass page->contents to pdf_new_pdf_device.
This object is assumed to be a dictionary (stream) that can be updated
with the Length and stream contents once the page writing process has
completed.
When we are rewriting a pdf page however, this can go wrong; page->contents
can be an array of objects. Not only this, in general it would be
possible for several pages to share the same page contents (or
maybe some of the elements of a page contents array). Updating one page
should not update the others.
We therefore update pdf_page_write to always create a new page->contents
object and use that.
Thanks to Michael Cadilhac for spotting the basic problem here.
|
|
|
|
Calling pdf_is_dict causes the file to seek. This is a bad thing
in a process that is running through the file. It's doubly bad, as
the thing it seeks to read may not be there as it might not have
been repaired yet.
So, instead of just keeping the 'most recent root that is a
dictionary', we change to keeping a list of the roots we have found
while parsing the doc. At the end we then check for the most recent
one that is a dictionary and use that.
|
|
When repairing a file we keep track of the most recent 'Root' entry
we have found. Only accept a new Root entry as a replacement if it
is a dictionary.
|
|
Simon Reinhardt points out that writexrefstream calls pdf_update_stream
on an object, rather than on a reference. The code as written fails to
do the update, and the updated file is broken.
I fix this here by updating pdf_update_stream to be able to work
with both objects and references. This is in contrast to his patch
which would create a reference for the sole purpose of performing
the update.
|
|
pdf_load_image_stream is supposed to return a buffer containing the
uncompressed stream from an object (or, in the case of image streams
where an fz_compression_params structure is supplied, a stream
decompressed up to the point of the image format compression).
We have an optimisation in pdf_load_image_stream to allow it to
return the existing buffer from a cached object rather than
reloading it again, but as bug 695549 points out, this breaks in
the case where the cached stream is compressed.
The suggested fix by the bug reporter (Stefan Klein) would work
in that it would stop compressed streams being returned as
uncompressed ones, but it is not perfect as it could lead to
several copies of shortstoppable image streams being loaded (and
for streams with null or empty array filters being mistaken for
compressed ones).
The fix here solves these cases too.
|
|
|
|
The actual fix implemented here is to bale out of pdf_write_document
if we are updating incrementally and the file has not changed.
|
|
Adopt a (trivially modified) patch provided by Simon Reinhardt.
When loading pdf outlines, if the 'Count' field is positive, the outline
entry should be considered open.
|
|
When making a new pdf_run_processor to handle type 3 glyph contents,
we can inherit the current gstate. Do NOT inherit the current clip
depth, as otherwise we pop too many on exit.
|
|
Move pdf-write.c over to calling fz_fprintf for all places in we need
printf, and fputs elsewhere.
|
|
Faster, shinier, better.
|
|
I broke this as part of the PDF Name refactoring.
|
|
Ensure that %010d works.
Ensure that we can output 64 bit values (%ll{d,u,x}).
Ensure that we can output size_t and fz_off_t (%z{d,u,x} and %Z{d,u,x}).
fz_off_t isn't defined yet (it will be introduced by a commit that
depends on this one), so for now, we put a stub definition in printf.c
that we will remove later.
|
|
Firstly, we make the definition of the path structures local to
path.c. This is achieved by using an fz_path_processor function to
step through paths enumerating each section using callback functions.
Next, we extend the internal path representation to include other
section types, including quads, beziers with common control points
rectangles, horizontal, vertical and degenerate lines. We also roll
close path sections up into the previous sections commands.
The hairiest part of this is that fz_transform_path has to cope with
changing the path commands depending on the matrix. This is a
relatively rare operation though.
|
|
Historically pdf_obj was a structure with a header and a union in it.
As time has gone by more stuff has been put into the header, and the
different arms of the union have changed in size. We've even adopted
the idea of different 'kinds' of pdf_obj's being different sizes
(names and strings for examples).
Here we rework the system slightly; we minimise the header, and split
out everything into different structures. Every different 'kind' of
pdf_obj is now it's own structure, just as big as it needs to be.
Key changes:
* refs is now a short rather than an int. We are never going
to need more than 32767 refs (indeed, if we ever need more
than about 3 (10 at the outside), something has gone very
wrong!). This aids structure packing.
* Only arrays, dicts and refs actually need the pdf_document
pointer.
* Only arrays and dicts need the parent_num pointer.
|
|
Currently, every PDF name is allocated in a pdf_obj structure, and
comparisons are done using strcmp. Given that we can predict most
of the PDF names we'll use in a given file, this seems wasteful.
The pdf_obj type is opaque outside the pdf-object.c file, so we can
abuse it slightly without anyone outside knowing.
We collect a sorted list of names used in PDF (resources/pdf/names.txt),
and we add a utility (namedump) that preprocesses this into 2 header
files.
The first (include/mupdf/pdf/pdf-names-table.h, included as part of
include/mupdf/pdf/object.h), defines a set of "PDF_NAME_xxxx"
entries. These are pdf_obj *'s that callers can use to mean "A PDF
object that means literal name 'xxxx'"
The second (source/pdf/pdf-name-impl.h) is a C array of names.
We therefore update the code so that rather than passing "xxxx" to
functions (such as pdf_dict_gets(...)) we now pass PDF_NAME_xxxx (to
pdf_dict_get(...)). This is a fairly natural (if widespread) change.
The pdf_dict_getp (and sibling) functions that take a path (e.g.
"foo/bar/baz") are therefore supplemented with equivalents that
take a list (pdf_dict_getl(... , PDF_NAME_foo, PDF_NAME_bar,
PDF_NAME_baz, NULL)).
The actual implementation of this relies on the fact that small
pointer values are never valid values. For a given pdf_obj *p,
if NULL < (intptr_t)p < PDF_NAME__LIMIT then p is a literal
entry in the name table.
This enables us to do fast pointer compares and to skip expensive
strcmps.
Also, bring "null", "true" and "false" into the same style as PDF names.
Rather than using full pdf_obj structures for null/true/false, use
special pointer values just above the PDF_NAME_ table. This saves
memory and makes comparisons easier.
|
|
Update buffer and filter processors.
Filter both colors and stroke states.
Move OCG hiding logic into interpreter.
|
|
|
|
|
|
We were failing to allow for the change in length of the hint
stream caused by the ascii encoding when calculating offsets.
|
|
MuPDF (and other PDF readers) treat invalid references as 'null'
objects. For instance, in the supplied file, object 239 is supposedly
free, but a reference is made to it.
When cleaning (or linearising) a file, we renumber objects; such
illegal refs then end up pointing somewhere else.
The workaround here is simply to spot the invalid refs during the
mark phase, and to set the referencing to null.
|
|
pdf_parse_file_spec sometimes extracts the wrong path from a FileSpec:
E.g. the /DOS path should never be returned under Unix systems, neither
should be the old /Mac paths.
For consistency, this patch also converts filesystem paths under
Windows into a format applications will expect (e.g. from "/C/path/..."
to "C:\path\...").
Finally, pdf_parse_file_spec is exposed to callers (SumatraPDF requires
that for manually processing FZ_ANNOT_FILEATTACHMENT and embedded files).
|
|
When watermarking, we may want to use the PDF device on an
existing buffer. In this case, we have no 'contents' object.
|
