Age | Commit message (Collapse) | Author |
|
|
|
When we run a display list we pass in an area for fast eliding of
objects. Ensure that the area we pass in is always at least as big
as the bbox with which we create display devices.
|
|
This is faster on ARM in particular. The primary changes involve
fz_matrix, fz_rect and fz_bbox.
Rather than passing 'fz_rect r' into a function, we now consistently
pass 'const fz_rect *r'. Where a rect is passed in and modified, we
miss the 'const' off. Where possible, we return the pointer to the
modified structure to allow 'chaining' of expressions.
The basic upshot of this work is that we do far fewer copies of
rectangle/matrix structures, and all the copies we do are explicit.
This has opened the way to other optimisations, also performed in
this commit.
Rather than using expressions like:
fz_concat(fz_scale(sx, sy), fz_translate(tx, ty))
we now have fz_pre_{scale,translate,rotate} functions. These
can be implemented much more efficiently than doing the fully
fledged matrix multiplication that fz_concat requires.
We add fz_rect_{min,max} functions to return pointers to the
min/max points of a rect. These can be used to in transformations
to directly manipulate values.
With a little casting in the path transformation code we can avoid
more needless copying.
We rename fz_widget_bbox to the more consistent fz_bound_widget.
|
|
|
|
Various functions in the code output to FILE *, when there are times
we'd like them to output to other things, such as fz_buffers.
Add an fz_output type, together with fz_printf to allow things to
output to this.
|
|
|
|
|
|
Inside the renderer we often deal with integer sized areas, for
pixmaps and scissoring regions. Use a new fz_irect type in these
places.
|
|
|
|
While investigating samples_mupdf_001/2599.pdf.asan.58.1778, a leak
showed up while cleaning the file, due to not dropping an object in
an error case.
mutool clean -dif samples_mupdf_001/2599.pdf.asan.58.1778 leak.pdf
Simple Fix. Also extend PDF writing so that it can cope with skipping
errors so we at least get something out at the end.
Problem found in a test file supplied by Mateusz "j00ru" Jurczyk and
Gynvael Coldwind of the Google Security Team using Address Sanitizer.
Many thanks!
|
|
A user (stu-mupdf) points out that if winopen fails, we throw
an error, which crashes due to the exception stack not having
been set up yet. The solution is simply to move pdfapp_init a
little earlier.
|
|
Thanks to zeniko for these.
Use otf as extension for opentype fonts.
fz_clampi should take ints, not floats!
Fix typo in prototype.
Squash unwanted warning.
Remove magic number in favour of #define.
Reset generation numbers when renumbering.
|
|
Only used in mujstest script generation.
|
|
Since adding transition support any page turn has leaked a bitmap
image. Don't save the old image unless we are really in transition
mode.
|
|
This stops all the warnings coming out on a single line.
|
|
MuPDF needs access to the original file when saving, and in any case
directly overwritting the original file has much more potential for
data loss than use of a temporary file.
|
|
|
|
Requires GNU make and gcc.
|
|
Also update pdf_dict_puts so that passing NULL to val deletes the terminal
key.
Update pdfapp.c to update the screen between passing a mouse event and
invoking a dialog box for value entry
Extend javascript wrapper to handle all color spaces
|
|
|
|
Regenerate dirty appearance streams and report changed annotations since
last call.
Also include a partial revert of changes in 96f335bc, that turn out not
to be necessary.
fz_update_page must now be called between each document-changing event and
the next render. pdfapp.c and the android app have been updated to do so,
but do not yet take advantage of the possibility to render only the updated
areas of the screen.
|
|
|
|
|
|
|
|
Only Fade, Wipe and Blinds supported so far.
Hit 'p' in the viewer to go into 'presentation' mode. Page swaps
then transition from page to page. Pages auto advance until key
or mouse is used.
|
|
Add pdf_update_annot, which is called before rendering an annotation, and
checks that the annotation structure has correct information. There are
three reasons the information can be out of date.
Attributes of a field may have been changed such that its appearance
stream needs updating. In this case the field will have have "Dirty"
added to its dictionary
The mouse may have changed state over the field, and a different
appearance stream needs selecting. The annotation structure now records
the mouse states for which the current appearance stream is acceptable.
The field may have changed state as recorded by its "AS" value, and a
different appearance stream needs selecting.
|
|
|
|
|
|
|
|
|
|
|
|
app.execDialog looks very difficult to support. Hopefully we wont have to
|
|
The name of the menu item is passed, so presumably the app could respond
to some of the possibilities.
|
|
|
|
Currently the app windows app responds with a message box explaining that
the MuPDF library passes print requests to the app, but the app does not
implement printing.
|
|
|
|
|
|
Conflicts:
cbz/mucbz.c
pdf/pdf_parse.c
pdf/pdf_form.c
xps/xps_zip.c
|
|
|
|
|
|
Previously this triggered an assertion in the cleanup code when
freeing the partially opened document.
|
|
Avoid the C++ code complaining about casting string literals
to non-const char *'s.
|
|
|
|
Conflicts:
Makefile
apps/mudraw.c
pdf/pdf_write.c
win32/libmupdf-v8.vcproj
|
|
Previously fix 13943b92f10796efb175e769afe5b0aea85d879a introduced
continued rendering of further pages for documents where one page
failed to load. However, if the entire page tree was missing from a
PDF document then no display list would be obtained, yet MuPDF tried
to render the display list causing a null pointer dereference. Now,
check for a valid display list before trying to render it.
|
|
|
|
|
|
pdf_write_document() may throw an exception and this was uncaught up
until now.
|
|
|
|
|