| Age | Commit message (Collapse) | Author |
|---|
|
Any pdf function with incorrect number of subfunction boundaries
will either cause an exception or have excessive boundaries be
ignored.
|
|
Any pdf functions with incorrect number of constants will have their
constant values set to default values. Any excessive constants are
ignored.
|
|
Exponential pdf functions have constraints on their input values so
warn about out of range values when loading those functions. When
evaluation the functions, assume zero without warning.
|
|
Functions that have excessive dimension sizes will have those sizes
ignored, whereas functions that have too few dimension sizes will
cause an exception.
|
|
After this pdf functions that have malformed Decode/Encode arrays with
too few/many entries compared to the number of inputs/outputs will be
handled more gracefully. Those missing mappings will be set to default
values.
|
|
Functions requiring more inputs than available input values will have
those inputs set to zero. Similarly functions producing too few
outputs will have the remaining output values be set to zero. Any
excessive input values or output values will be ignored.
|
|
Both exponential and stitching functions are limited to having one
input. Make sure that any excessive inputs are ignored.
|
|
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
|
|
Variable i can never be zero at this point. The desired point of testing
against i was to ensure that the test did not evaluate true at the
first run, and the other parts of the condition are sufficent to
ensure this, so just remove the test on i.
|
|
Since the commit to replace abs/min/max/clamp with inline versions,
"1522 - diagramm missing above 88 pc zoom.pdf" has been missing a
diagram. This is because the diagram contains sections like:
-2147483648 -2147483648 m
-2147483648 2147483647 l
2147483647 2147483647 l
2147483647 -2147483648 l
These extreme values, when transformed would give floating point values
that when naively cast down to int, flip sign (e.g. extreme positive
when cast to int becomes extreme negative).
I had been relying on the cast down giving sane results to enable me to
use fz_clampi. Revert to using fz_clamp and all is fine.
|
|
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.
|
|
The FT_Stroker doesn't support dash patterns. Fall back to the normal
path rendering, same as with glyphs that are too big to fit the cache.
|
|
|
|
Shear by 20 degrees for italic. Use 2% wider metrics for bold.
|
|
|
|
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
|
|
Acrobat seems to cope, we should too. See normal_439.pdf for an
example.
|
|
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.
|
|
normal_994.pdf SEGVs due to a negative length. Simple fix to treat
negative length streams as 0 length.
|
|
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.
|
|
When writing few enough bits that they would fit into the 'spare' bits
in the last byte, I was failing to update the buffer.
Also, I was failing to grow the buffer enough, and calculating the
wrong number of bits left over in various places.
Both fixed here. Thanks to Robert Jedrzejczyk and Sebras!
|
|
Solves problem seen in torture.pdf - we now match acrobat.
Problem derived from normal_262.pdf
|
|
|
