| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
|
|
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
|
|
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).
|
|
If we perform a linejoin that ends up being over an impossibly small
distance, we can get a rendering error. This is caused by trying to
calculate scale = linewidth/sqrtf(len), where len < FLT_EPSILON.
Avoid this by rearranging the code slightly - no extra calculations
required.
Also given that sn == bn at all times within the stroking code, just
remove bn.
Credit for spotting this problem goes to Simon for tracking the
problem with rounding_artifact_due_to_closepath.pdf. My fix just
fixes the problem at a lower level than his does.
|
|
fz_draw_clip_text changes the value of 'state' during a loop. The
'if (glyph)' part of the loop assumes that it points to gstate[top-1]
where the 'path' part of the loop changes it to point to gstate[top].
If we render a "non glyph" glyph, then a "glyph" glyph, we will access
an invalid state. This can cause a draw_glyph call on an invalid
destination bitmap.
The fix is simply not to reset state.
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the fuzzing files.
|
|
For SumatraPDF, the following changes are required:
* fz_load_system_font is called from pdf_load_builtin_font as well so
that Arial, Courier New, etc. can be loaded from the system instead
of their Nimbus replacements. In order to distinguish between calls
from pdf_load_builtin_font and pdf_load_substitute_font, an
is_substitute argument is added.
* fz_load_system_cjk_font is added and called from
pdf_load_substitute_cjk_font so that a better replacement font can
be loaded instead of DroidSansFallback.
* Both fz_load_system_font and fz_load_system_cjk_font return fz_font*
instead of fz_buffer* so that implementers aren't required to load
fonts into memory (SumatraPDF uses fz_new_font_from_file for system
fonts).
In addition to that, fz_load_system_font_func is renamed to
fz_load_system_font_funcs since it now accepts two functions, and the
PDF_ROS_* constants are renamed to FZ_ADOBE_* (collection names aren't
passed as const char* so that implementers know which collections to
expect). For convenience, fz_load_*_font also never throws since
currently all callers have further fallbacks available.
|
|
This can be seen e.g. in:
5db811ac25ef543fd0cfa0873e155329_signal_sigsegv_c9b60f_9636_76.pdf
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
|
|
Remember to make blocks defined before writing/reading them.
|
|
Problems caused by the fact that -0x8000000 = 0x80000000.
Sidestep the problem for all coords where floats cannot accurately
represent them.
|
|
The gel bbox was being stored internally as floats (despite
only holding ints). This means that as numbers get large the
bbox can become approximate, rather than exact. If the bbox
becomes smaller than it should, this causes crashes in the
scanline filling code.
This is seen with:
tests_private/fuzzing/mupdf2/17f8aee51ac776994af0b36195cdadd7_signal_sigsegv_5607be_7308_5912.pdf
The solution is simply to use ints rather than floats.
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the example files.
|
|
If a file specifies a silly number of bpp in the PNG predictor it can
overrun a buffer. This was shown by:
tests_private/fuzzing/mupdf2/013b2dcbd0207501e922910ac335eb59_*.pdf
but no longer shows up due to Simons earlier fix.
Following discussion we still think it's worth having this fix in, as
truncated data streams can cause len < bpp. Possibly we should throw
an error here, but I think that's not necessary as we will return the
short length, and the image reading code will notice that the image
is truncated already.
Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security
Team for providing the fuzzing files.
|
|
If columns is quite close to INT_MAX, the column index max overflow
in find_changing which causes an access violation in the next getbits.
This happens e.g. with
0c76a20163f30ea8ec860c4e588ce337_signal_sigsegv_5e7b28_9115_7127.pdf
|
|
This fixes a NULL pointer dereference in
2192b04848b2d8210d1a33e3ddeb2742_asan_heap-oob_a5a57d_2745_2844.pdf
Also, replace MAXC with FZ_MAX_COLORS.
|
|
We define a document handler for each file type (2 in the case of PDF, one
to handle files with the ability to 'run' them, and one without).
We then register these handlers with the context at startup, and then
call fz_open_document... as usual. This enables people to select the
document types they want at will (and even to extend the library with more
document types should they wish).
|
|
This bug shows 2 problems with our data handling.
Firstly, if a zip file entry has less data in the stream than it
is declared to have, we would leave the end of the data uninitialised.
We now put out a warning, and blank it with zeros.
Secondly, if the PNG decompression fails to decode enough data, we
don't notice. Now we give a warning and blank the remaining pixels.
|
|
Certain optimized documents use a rather large common symbol dictionary
for all JBIG2 images. Caching these JBIG2Globals speeds up loading and
rendering of such documents.
|
|
This helps debugging issues with JBIG2 images.
Conflicts:
source/fitz/filter-jbig2.c
|
|
See SumatraPDF's repo for a Windows-only implementation using WIC.
|
|
Some warnings we'd like to enable for MuPDF and still be able to
compile it with warnings as errors using MSVC (2008 to 2013):
* C4115: 'timeval' : named type definition in parentheses
* C4204: nonstandard extension used : non-constant aggregate initializer
* C4295: 'hex' : array is too small to include a terminating null character
* C4389: '==' : signed/unsigned mismatch
* C4702: unreachable code
* C4706: assignment within conditional expression
Also, globally disable C4701 which is frequently caused by MSVC not
being able to correctly figure out fz_try/fz_catch code flow.
And don't define isnan for VS2013 and later where that's no longer needed.
|
|
The SVG device needs rebinding as it holds a file. The PDF device needs
to rebind the underlying pdf document.
All documents need to rebind their underlying streams.
|
|
|
|
|
|
Add a cached color converter mechanism. Use this for rendering meshes
to speed repeated conversions.
This reduces a (release build to ppm at default resolution) run from
23.5s to 13.2 seconds.
|
|
In the existing code for meshes, we decompose the mesh down into
quads (or triangles) and then call a process routine to actually
do the work. This process routine typically maps each vertexes
position/color and plots it.
As each vertex is used several times by neighbouring patches, this
results in each vertex being processed several times. The fix in
this commit is therefore to break the processing into 'prepare' and
'process' phases. Each vertex is 'prepared' before being used in
the 'process' phase. This cuts the number of prepare operations in
half.
In testing, this reduced the time for a (release build, generating ppm
at default resolution) run from 33.4s to 23.5s.
|
|
Remove code that's not used any more as a result of the previous
fix, plus some code that was unused anyway.
|
|
Avoid unnecessary copies. Minimise calls to isbigendian.
|
|
This is required for e.g. 1980_-_compressed_inline_image.pdf and
Bug690300.pdf .
|
|
The pattern repeat calculation should be done in pattern space, but
one of the arguments in the calculation was being taken from device
space. Fix this. Also only apply the bias in the case where the
bias would make it larger.
173 progressions.
|
|
Simple typo. Thanks to Alexander Monakov for spotting this.
|
|
It seems that (int)-98.5 = 98, not -99. Use floorf instead.
|
|
The changes to fz_render_glyph cause the scissor rectangle to no longer
match the transformation matrix which causes Type 3 glyphs to be
clipped at larger resolutions.
|
|
ft_file was removed in a2c945506ea2a2b58edbde84124094c6b4f69eac even
though it might still be needed by downstream consumers (such as
SumatraPDF) for allowing devices to load fonts again when a font has
been loaded by fz_new_font_from_file which doesn't maintain a buffer.
|
|
The actual issue here is that a pixmap is dropped more times than
it should be due to an error in the rendering pipeline.
The problem arises because we fail to push a clip image mask, but
still pop the mask off the stack later. This puts us off by 1 in
the stack handling.
The simplest solution to this (that will be safe no matter what
mistakes are made by the caller too) is to add some simple tests
in the draw device to ensure we do not free too early.
|
|
|
|
|
|
|
|
Use fz_buffer to wrap and reference count data used in font.
|
|
|
|
Add a function to clone stroke states, a magic number to keep in the
reference count to signal that a stroke state is stack-stored, and
automatically clone stack stored stroke states in the keep function.
Use fz_default_stroke_state to initialise stack stored stroke states.
|
|
Self balancing AA-tree.
|
|
Print node and children, not node, children and siblings.
|
|
|
|
|
|
windows settings.
|
|
Image masks don't have a colorspace; check before dereferencing.
|
