| Age | Commit message (Collapse) | Author |
|---|
|
Suppose an application that uses MuPDF implements its own
allocator that limits the amount of memory that may be allocated.
When that condition occurs fz_malloc() will throw an exception,
this exception would then be thrown right back to MuPDF without
allowing for libjpeg to free any of the memory it has allocated.
After this commit fz_malloc_no_throw() is called, which under the
same conditions would simply return NULL. allowing for libjpeg to
free what ever allocations it has done, and return to MuPDF with
an error just like before.
|
|
For TIFF it was not just the colorspace, but other data as well.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
These are called from fz_new_image_from_buffer.
|
|
|
|
|
|
Previously, in case of error in fz_jpg_mem_init(),
jpeg_finish_decompress()/jpeg_destroy_decompress()
would be called before jpeg_create_decompress() had
initlized all state. This sometimes led to segfaults
or accessing uninitialized data.
|
|
Update separations interface further to cope with whether spots
should be rendered separately, or as composite colors.
|
|
|
|
In commit 6a8abce9603f69b57e407f0df4044be919f507d7 an
agnostic memory handler was introduced for libjpeg. While
this commit changed error_exit_dct() it forgot to make a
similar change in error_exit().
|
|
This silences the many warnings we get when building for x64
in windows.
This does not address any of the warnings we get in thirdparty
libraries - in particular harfbuzz. These look (at a quick
glance) harmless though.
|
|
|
|
fz_pixmaps now have an explicit stride value. By default no change
from before, but code all copes with extra gaps at the end of the
line.
The alpha data in fz_pixmaps is no longer compulsory.
mudraw: use rgb not rgba (ppmraw), cmyk not cmyka (pkmraw).
Update halftone code to not expect alpha plane.
Update PNG writing to cope with alpha less input.
Also hide repeated params within the png output context.
ARM code needs updating.
|
|
Reintroduce fz_load_jpeg() (previously removed in 12c1466) improved with:
* application agnostic memory handler support from 6a8abce
* colorspace context from 93bd1ff
* resolution detection from 4dc6cbe
|
|
We compile with -Wno-unused-parameters instead.
|
|
With this change, all 32-bit values read from untrusted data through
read_value are compared unmodified in order to prevent unintended
integer overflows during the comparison.
|
|
|
|
This adds a custom memory management layer between libjpeg and the calling
app - in such a way that the code can be shared between mupdf and
Ghostscript/PDL.
|
|
There are two issues where variables may be used unitialized:
* extract_exif_resolution fails to set xres and yres for JPEG images if
there's no valid resolution unit (mainly affects XPS documents)
* xps_measure_font_glyph uses hadv and vadv unitialized if the glyph id
isn't valid (i.e. if FT_Get_Advance fails)
|
|
XPS extracts the resolution of a JPEG image from the image data. The
current code however only reads the density values provided by JFIF
metadata, while the XPS specification also allows for resolution to be
in either EXIF metadata or Photoshop's APP13 chunk. This patch adds
code for reading both kinds of metadata in order to get more consistent
behavior with Microsoft's XPS Viewer. Documents for reproducing this issue:
2093*.xps, 2249*.xps, 2252*.xps, 2268*.xps and "jpeg exif resolution.xps".
Another detail: The default resolution for JPEG images in XPS documents
is 96 DPI and not 72 DPI.
|
|
|
