Age | Commit message (Collapse) | Author |
|
This will allow the loading of pdf functions to validate that a pdf
function has the correct number of inputs/outputs. Additionally it
will allow for handling pdf functions with incorrect number of
inputs/outputs.
|
|
Previously a pdf function having too many inputs or outputs would
cause and exception, now they will be handled silently.
There are two places pdf functions are used: for shadings and for
colorspace tint transforms. In both cases the number of inputs/outputs
may never be more than the number of components, i.e. limited to MAXN.
Additionally the number of inputs/outputs may never be less than than
the number of components, and there is always at least one component.
|
|
BitsPerSample is already screened later in the code for invalid
values, including the default value 0 returned by pdf_to_int().
|
|
|
|
Encryption keys lengths are expressed in bits, however
one check assumed the length was expressed in bytes.
|
|
Fixes bug #692267
|
|
Fixes bug #692289
|
|
Always use BaseFont, always ignore font descriptor's FontName.
|
|
|
|
Fix bug http://code.google.com/p/sumatrapdf/issues/detail?id=1618
|
|
Fixes http://code.google.com/p/sumatrapdf/issues/detail?id=1815
|
|
Fixes bug where Symbol is not embedded but encoded as a TrueType but the
built-in font is a Type1.
http://code.google.com/p/sumatrapdf/issues/detail?id=1310
|
|
Also strip the subset prefix.
|
|
Improves text device output when using substitute fonts.
Fixes bug #693019.
|
|
Warn instead of throwing an error. Fixes file in
http://code.google.com/p/sumatrapdf/issues/detail?id=1842
|
|
Since I implemented linearisation, any invocation that hasn't used
garbage collection has produced broken files, due to every object
being marked as freed. This was because I'd forgotten to ever set
the use_list markers to be 1. Fixed here.
|
|
|
|
While pdf writing, compactxref would fail to take into account
that duplicated objects would have been mapped down to a lower
number, and the use_list value for the upper one would be set to
zero.
Thanks to Zeniko for pointing out this fix.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If an error occurs early enough we can end up trying to free an
uninitialised pointer. Simply set it to NULL to start with.
Problem seen with normal1265.pdf
|
|
normal_457.pdf specifies an alpha value of 1.005, which causes overflows
when calculating values. Simply clamp values into the 0..1 range.
|
|
Instead of using macros for min/max/abs/clamp, we move to using
inline functions. These are more typesafe, and should produce
equivalent code on compilers that support inline (i.e. pretty much
everything we care about these days).
People can always do their own macro versions if they prefer.
|
|
for(i = 0; i < pdf_array_len(x); i++)
...
results in lots of calls to pdf_array_len. This is not what we want.
|
|
In pdfwrite we have a flag to say "don't expand images", but this
isn't always honoured because we don't know that a stream is an
image (for instance the corrupt fax stream used as a thumbnail
in normal_439.pdf).
Here we update the code to spot that streams are likely to be
images based on the filters in use, or on the presence of both
Width and Height tags.
|
|
Solves problem seen in torture.pdf - we now match acrobat.
Problem derived from normal_262.pdf
|
|
For example "Symbol,Italic" can be handled as an artificially
obliqued "Symbol".
Fixes an issue in test file normal_161.pdf
|
|
In PDF the text rendering mode can have bit 2 set to mean "add to clipping
path". Experiments (and in particular normal_130.pdf) show that the text
should be stroked and/or filled BEFORE the path is added to the clipping
path.
|
|
Remove unused variable, silencing compiler warning.
No need to initialize variables twice.
Remove initialization of unread variable.
Remove unnecessary check for NULL.
Close output file upon error in cmapdump.
|
|
Currently pdf_lexbufs use a static scratch buffer for parsing. In
the main case this is 64K in size, but in other cases it can be
just 256 bytes; this causes problems when parsing long strings.
Even the 64K limit is an implementation limit of Acrobat, not an
architectural limit of PDF.
Change here to allow dynamic buffers. This means a slightly more
complex setup and destruction for each buffer, but more importantly
requires correct cleanup on errors. To avoid having to insert
lots more try/catch clauses this commit includes various changes to
the code so we reuse pdf_lexbufs where possible. This keeps the
speed up.
|
|
|
|
|
|
These functions currently call pdf_array_put, but this fails to
extend the array. Change to use pdf_array_push instead.
|
|
|
|
|
|
After commit 120dadb, it's far too easy to get into a seemingly infinite
loop while processing a corrupt file.
We fix this by changing the process to abort when we receive an invalid
keyword.
Also, we add another layer of nesting to pdf_run_stream to avoid us
push/popping an fz_try level on every keyword.
|
|
The file supplied with the bug contains corrupt jpeg data on page
61. This causes an error to be thrown which results in mudraw
exiting.
Previously, when image decode was done at loading time, the error
would have been thrown under the pdf interpreter rather than under
the display list renderer. This error would have been caught, a
warning given, and the program would have continued. This is not
ideal behaviour, as there is no way for a caller to know that there
was a problem, and that the image is potentially incomplete.
The solution adopted here, solves both these problems. The fz_cookie
structure is expanded to include a 'errors' count. Whenever we meet
an error during rendering, we increment the 'errors' count, and
continue.
This enables applications to spot the errors count being non-zero on
exit and to display a warning.
mupdf is updated here to pass a cookie in and to check the error count
at the end; if it is found to be non zero, then a warning is given (just
once per visit to each page) to say that the page may have errors on it.
|
|
Extend mupdfclean to have a new -l file that writes the file
linearized. This should still be considered experimental
When writing a pdf file, analyse object use, flatten resource use,
reorder the objects, generate a hintstream and output with linearisaton
parameters.
This is enough for Acrobat to accept the file as being optimised
for Fast Web View. We ought to add more tables to the hintstream
in some cases, but I doubt anyone actually uses it, the spec is so
badly written. Certainly acrobat accepts the file as being optimised
for 'Fast Web View'.
Update fz_dict_put to allow for us adding a reference to the dictionary
that is the sole owner of that reference already (i.e. don't drop then
keep something that has a reference count of just 1).
Update pdf_load_image_stream to use the stm_buf from the xref if there
is one.
Update pdf_close_document to discard any stm_bufs it may be holding.
Update fz_dict_put to be pdf_dict_put - this was missed in a renaming
ages ago and has been inconsistent since.
|
|
Needs more work to use the linked list of free xref slots.
|
|
Make a separate constructor function that does not link in the
interpreter, so we can save space in the mubusy binary by not
including the font and cmap resources.
|
|
|
|
|
|
mupdfclean (or more correctly, the pdf_write function) currently has
a limitation, in that we cannot renumber objects when encryption is
being used. This is because the object/generation number is pickled
into the stream, and renumbering the object causes it to become
unreadable.
The solution used here is to provide extended functions that take both
the object/generation number and the original object/generation
number. The original object numbers are only used for setting up the
encryption.
pdf_write now keeps track of the original object/generation number
for each object.
This fix is important, if we ever want to output linearized pdf as
this requires us to be able to renumber objects to a very specific
order.
We also make a fix in removeduplicateobjects that should only
matter in the case where we fail to read an object correctly.
|
|
Currently, if a page stream cannot be read, mupdf gives an alert box
and then exits. This is annoying when reading a large pdf.
Here we change the code to only exit if a page is completely broken;
in the case of missing page contents, or missing links, we give a warning
and just render the best we can.
Also, update a couple of error messages to be less misleading.
|