| Age | Commit message (Collapse) | Author |
|---|
|
I can't claim to entirely understand why one formulation works and
the other doesn't, but it seems a harmless enough fix that apparently
works.
|
|
Based on changes supplied by mt-82@gmx.org, but bent to be more
in keeping.
The actual building with MINGW is untested. We merely verify that
these do not break the existing builds. With a bit of luck they
should work though.
|
|
|
|
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.
|
|
My recent changes to support %010Zd were broken in many interesting
ways. Fixed here.
|
|
|
|
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.
|
|
Introduce the concept of 'packed' paths. These reduce the header
overhead for most common paths (ones with less than 256 commands
and 256 coords) to a single 32bit int once stored in the
display list.
The previous commit reduces the torture-test.pdf from 95 to 87Meg.
This commit futher reduces it to 70Meg.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fred had updated a path in an include file. The Makefiles cope with
this, the VS solution does not.
|
|
|
|
The lib was being built in an odd place.
|
|
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.
|
|
Also a few fixes in the project files based upon recent updates.
|
|
|
|
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.
|
|
In order to be able to watermark etc, we want the ability to
add more operators/resources after page cleaning.
Add a post processing hook to enable this to be done more
easily.
|
|
Add missing initialisation of glo.ctx required due to API
change.
|
|
A few casts are required within the code, along with a few #ifdef
changes.
Some tweaks to curl are required too.
|
|
|
|
|
|
This silences this warning:
thirdparty/jbig2dec/jbig2_text.c:899:73: warning: for loop has empty body [-Wempty-body]
for (SBSYMCODELEN = 0; (1 << SBSYMCODELEN) < SBNUMSYMS; SBSYMCODELEN++);
^
thirdparty/jbig2dec/jbig2_text.c:899:73: note: put the semicolon on a separate line to silence this warning
|
|
There are a fair number of warnings about unused functions, mostly in
third-party modules, and we would like the build to be warning free.
We need to change the main Makefile, as -Wall is currently added in
Makerules, and we need our -Wno-unused-function in XCFLAGS to be
after -Wall on the command line for it to have any effect.
|
|
|
|
|
|
Silly oversight.
|
|
Update android Core.mk file for html document handler, and fix a
stray fz_free_page that didn't get updated.
|
|
We were not filling in the matrix and bbox fields for images
collected as part of the text extraction device. Fixed here.
|
|
When we meet cached tiles when rendering the display list, we need to
skip over their contents. Previously we did this by skipping
display list nodes in their entirety.
With the new display list scheme however, we cannot simply skip
nodes completely as the graphic state changes must be remembered.
We therefore update the list playback routine to keep track of the
clip depth and to skip the function calls as required.
|
|
I was testing an untransformed rectangle. This was not being picked up
as our cluster tests use the identity matrix.
|
|
Add the new source files to the solution.
Windows builds whinge about float->double conversions. Fix these
with explicit casts.
Avoid calling strtof and strcasecmp.
|
|
The example file for this bug has an invalid font bbox. The current
code uses this bbox (or some multiple of it) to clip the glyphs
size.
In the new code, when we convert the glyphs to display lists we
watch for the bbox given in any d1 operator used. If we find one,
we gather the rectangle specified and store it as the glyph rectangle
in the fz_font.
If we then attempt to bound a glyph that used d1, it happens instantly
without needing to run the list. This seems to match acrobats behaviour.
Tests indicate that Acrobat never clips d0 glyphs, so our behaviour
is still different here, but I am not changing this at the moment.
Also, I note that t3flags should be a un unsigned short but are currently
just a char. Fix that too.
Also fix some missing code in fz_new_font that would cause leaks if mallocs
failed.
|
|
Move the logic in pdf_show_char to use the same idiom as used
elsewhere. Specifically this ensures that empty rects are
handled correctly.
|
