| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The following changes allow font providers to make better choices WRT
what font to provide and under what circumstances:
* bold and italic flags are passed in so that implementors can decide
themselves whether to ask for simulated boldening/italicising
if a font claims not to be bold/italic
* is_substitute is replaced with needs_exact_metrics to make the
meaning of this argument hopefully clearer (that argument is set only
for PDF fonts without a FontDescriptor)
* the font name is always passed as requested by the document instead
of the cleaned name for the standard 14 fonts which allows
distinguishing e.g. Symbol and Symbol,Bold
|
|
|
|
|
|
|
|
and give them names more likely to be unique.
|
|
|
|
|
|
Many times, the idiom p.x = x; p.y = y; fz_transform_point() is used.
This function should simplify that use case by both initializing and
transforming the point in one call.
|
|
|
|
This feature is being implemented mostly for the purpose of permitting
the addition to a page of invisible signatures.
Also change pdf_create_annot to make freshly created annotations
printable by default.
|
|
|
|
Use a fixed number for Math.random().
Return a fixed date for Date.now() and Date.UTC().
|
|
|
|
|
|
Make the scoping clearer, since Javascript doesn't have block scoping.
|
|
|
|
|
|
|
|
see https://code.google.com/p/sumatrapdf/issues/detail?id=2517 for a
document which is broken to the point where it fails to load using
reparation but loads successfully if object 0 is implicitly defined.
|
|
|
|
Patch from Thomas Fach-Pedersen. Many thanks!
Add a new format handler that copes with TIFF files. This replaces
the TIFF functionality within the image format handler, and is
better because this copes with multiple images (as one image per
page).
|
|
Patch from Thomas Fach-Pedersen. Many Thanks.
|
|
Patch from Thomas Fach-Pedersen to fix the operation of pdf_insert_page
when called with an empty page tree. Many thanks! As noted in the code
with a FIXME this currently throws an error.
Also, cope with being told to add a page "at" INT_MAX as meaning to
add it at the end of the document.
Possibly this code should cope with a Root without a Pages entry, or
a Pages without a Kids too, but we can fix this in future if it ever
becomes a problem.
|
|
This makes every pdf_run_XX operator function have the same function
type. This paves the way for future changes in this area.
|
|
Acrobat honours Tc and Tw operators found during parsing TJ arrays.
We update the code here to cope. Possibly to completely match we should
honour other operators too, but this will do for now.
This maintains the behaviour of
tests_private/pdf/sumatra/916_-_invalid_argument_to_TJ.pdf 916.pdf
and improves the behaviour in general.
|
|
Useful utility missing from our arsenal.
|
|
Reuses the same internals as pdf_fprintf_obj etc.
|
|
String.prototype.substr() is deprecated.
RegExp.prototype.compile() has never been part of the ECMA standard,
and is deprecated in Mozilla's Javascript since 1.5 (at least).
|
|
Luiz Henrique de Figueiredo reports that glyphs output from the
SVG device contain 'lumpy' outlines. Investigation reveals that
this is because the current code extracts the outlines from
freetype at unit scale, and then relies on SVG to scale them up.
Unfortunately, freetype insists on working in integer maths, so
any sort of scaling runs the risk of distorting the outlines.
The fix is to change the way we call freetype; we now request an
'UNSCALED' char, and set the required size to be the design size.
We then transform the results in the floating point domain
ourself.
This cures the lumpy outlines, but reveals a second problem,
namely that the bbox given for characters is inaccurate (and
sometimes too small). Investigation shows that this is again
caused by freetypes scaling, so we apply the same trick; ask
for the glyph without scaling (as far as possible), and then
scale the results down.
We also take care to spot the 'ft_hint' flag in the font. If set
this indicates that hinting must be performed to ensure that
the returned outlines are sane. We therefore take note of this
when calculating both bbox and outlines. This means that 'tricky'
fonts such as dynalab ones now render correctly.
This produces many changes in the bitmaps, the vast majority of which
are neutral. The ones that aren't are all progressions.
|
|
|
|
|
|
|
|
Arrays are intended for numeric arrays, since they have the magic
updating of their "length" property which regular objects lack.
|
|
The test file on this bug:
de53b4bd41191f02d01a3c39b4880fa8_asan_heap-oob_caba3c_9561_7427.pdf
includes a corrupt CMAP. When this is read into memory it produces
a CMAP where the table gets too large. This produces lots of warnings
from 'add_table', but the calls to add_table all assume that the
process completed fine, resulting in range entries being added
that point to nonexistent values.
The fix is to make add_table return a bool to indicate success or
failure, and to only add range entries if the add_table succeeds.
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
|
|
Change the library copying to use a system variable for the location that works in both builds
|
|
|
|
When we call pdf_begin_group, this can go away and do lots of
drawing. This can result in the gstate stack growing, which can
involve a realloc. Any gstate pointer we are holding must therefore
be recalculated after such a call.
The neatest way to do this is to get pdf_begin_group to return
the gstate pointer, thus making it hard to forget to do.
This solves:
e2a1dda5393f4cb8a446fd8edd9d94f9_asan_heap-uaf_b938cf_2075_2393.pdf
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
|
|
If the scale is too large, the calculation to determine the
required size of a pixmap can overflow. This can lead to negative
width/heights being passed in, which confuses the subsampling
code, leading to SEGVs.
|
|
Seen when valgrinding a memento build of mudraw on:
e0e44ed8692671b820de72c6c0a32608_asan_heap-uaf_8c2b76_1530_2026.pdf
|
|
When we find certain classes of flaw in the file while attempting to
read an object, we trigger an automatic repair of the file. This
leaves almost all objects unchanged; the sole exception is that of
the trailer object (and its sub objects) which can get dropped and
recreated.
To avoid leaving people holding handles to objects within the trailer
dict high and dry, we introduce a 'pre_repair_trailer' object to
each xref entry. On a repair, we copy the existing trailer object to
this. As we only ever repair once, this is safe.
The only known place where this is a problem is when setting up the
pdf_crypt for a document; we adapt the code here to allow for
potential problems.
The example file that shows this up is:
048d14d2f5f0ae31e9a2cde0be66f16a_asan_heap-uaf_86d4ed_3961_3661.pdf
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the fuzzing files.
|
|
If the /Version is a single character string (say "s") then the
current code for converting this in pdf_init_document reads off
the end of the string.
Simple fix is to use fz_atof instead.
Same fix for reading the PDF version normally.
This solves:
53b830f849d028fb2d528520716e157a_asan_heap-oob_478692_5259_4534.pdf
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
|
|
Lost as part of the accidental VS2012 change.
|
|
xps_parse_color happily reads more than FZ_MAX_COLORS values out of a
ContextColor array which overflows the passed in samples array.
Limiting the number of allowed samples to FZ_MAX_COLORS and make sure
to use that constant for all callers fixes the problem.
Thanks to Jean-Jamil Khalifé for reporting and investigating the issue
and providing a sample exploit file.
|
|
|
|
fz_new_image_from_pixmap expects that the pixmap's colorspace has two
references which is contrary to expectations. If it instead addrefs the
pixmap's colorspace, the only caller pdf_load_jpx can consistently
drop the colorspace after passing it to fz_load_jpx.
Also, if the contract is that whatever is passed into
fz_new_image_from_pixmap belongs to the new image, then the pixmap also
has to be dropped on error so that it isn't leaked.
|
|
Using JDCT_FASTEST as rendering method can produce visible artifacts
(e.g. in 1960_-_DCT_image_wrongly_decoded_regression_from_1.2_.pdf).
|
|
When we call to execute a pattern, we clear out the pdf_csi (the
interpreter state). This involves clearing the stack and throwing
away the record of the object we have just parsed.
Unfortunately, when filling glyphs with a pattern, that object is
still in use. We therefore amend the pdf_run_contents_stream to
safely stash the object away and restore it afterwards.
This solves this problem, and protects us against any other similar
problems that might also arise.
This solves:
b8e2b57991896bf8120215cfbf7b54bb_asan_heap-uaf_86064f_2362_2587.pdf
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
|
|
|
|
To share as much code as possible between the Windows 8 app, windows phone app
and Windows desktop app, remove dependencies of Platform and Windows::Foundation
in files that interface to mupdf and replace with C/C++ std methods.
|
