| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Keep a list of currently open pages for each document. Attempting to
load a page that is already loaded will return the same instance again.
|
|
|
|
There is a regression for 2325_-_JPX_image_with_padding_rejected.pdf.
Object 3 in that document is a JPX-encoded image. Its EOC marker is
preceded by two extra bytes of data, 0x80 0x80. This makes the file
broken according to the JPEG 2000 specification.
Acrobat Reader and the Kakadu JPX decoder accepts this file without
issues, so OpenJPEG 2.1.0 added code to fix this (bug 226, commit
005e75bdc). That fix detects exactly two bytes of 0x80 0x80, a rather
brittle fix. Adding more padding or changing the padding byte values
is not accepted. Adding more padding is acceptable to Acrobat Reader
and Kakadu. An unrelated fix for another problem has since broken
OpenJPEG's support for this broken image.
|
|
|
|
This removes the need for unistd.h, which isn't around on
VS2005.
Also remove unused variable.
|
|
|
|
The upsampling code in the JPX decode attempted to guess a
suitable upsampling factor. The guessed factor was wrong,
causing writes of samples outside of the decoded image buffer.
Simply limiting the coordinates to the image buffer would
not suffice because the factor was wrong for every upsampled
row of pixels. openjpeg does provide an upsampling factor,
so use that instead and also take the component offsets into
account when decoding components into the pixmap. Combined
this resolves the issue that previously triggered ASAN.
Thanks to oss-fuzz for reporting.
|
|
pdf_page_transform() may throw due to a cycle in the page tree.
When this happened mupdf would previously forget to drop the
default colorspaces obtained, after this commit they are dropped.
Thanks to oss-fuzz for reporting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This requires subclasses of Device to implement its full interface.
It also makes the compiler complain if there is a difference between
the interface in Device and its subclasses. The drawback is that
all Devices are required to implement all methods, but that is an
easy hurdle to overcome. This change found the discrepancies between
the Device, NativeDevice and TraceDevice interfaces fixed in the
previous commits.
|
|
Several previous updates to the Device interface required updates
to TraceDevice but were forgotten.
|
|
|
|
|
|
|
|
|
|
Not popping causes assert to be triggered in fz_draw_end_group().
|
|
Abstract methods in interfaces offer no implementation and are
implicitly declared public, making a public access modifier
redundant.
|
|
|
|
|
|
|
|
|
|
Not popping causes assert to be triggered in fz_draw_end_group().
|
|
|
|
|
|
This makes it possible to change the colorspace when encountering
ICC colorspaces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unlikely that this could be an issue, but lets add it for safety.
|
|
|
|
Ensure that the generated libmupdf includes all library
dependencies within it. This makes life easier for people linking
MuPDF into their own projects as there is just one lib to include
rather than a range of them that vary according to condfiguration.
Fix 64bit Memento builds of libpkcs7.
Remove double definitions of jpeg_get_small etc that are now
shown up because of the libraries being merged into one.
|
|
Previously there was no visibility as to what the error was.
|
|
fz_fill_path() may throw an exception halfway through
pdf_show_path(), which in this case would not attempt to end any
begun groups or softmasks. This led to e.g. leaks of pixmaps held
by a group that was never ended.
Moving the cleanup to the always block is not foolproof because
the cleanup code itself may also throw exceptions, hence
preventing the end of the fz_always block from being executed.
This commit does put pdf_show_path() in the same situation as
pdf_run_xobject() that has the same problem with its cleanup
code.
Thanks to oss-fuzz for reporting.
|
|
fz_open_jbig2d() is called at two locations in MuPDF. At one
location a reference to the JBIG2 globals struct was taken before
passing it to fz_open_jbig2d(). At the other location no such
reference was taken, but rather ownership of the struct was
implicitly transferred to fz_open_jbig2d(). This inconsistency
led to a leak of the globals struct at the first location.
Now, passing a JBIG2 globals struct to fz_open_jbig2d() never
implictly takes ownership. Instead the JBIG2 stream will take a
reference if it needs it and drops it in case of error. As usual
it is the callers responsibility to drop the reference to the
globals struct it owns.
|
