Age | Commit message (Collapse) | Author |
|
|
|
Update FZ_VERSION to 1.7
Update Android app version.
|
|
Add margins of 1 em at the top and bottom of every page at the top level.
TODO: This should be set from the CSS using the @page selector, and be
collapsed with the body margins at the start and end of each chapter, as well
as the left and right body margins.
|
|
|
|
|
|
Trigger the default layout when needed, but only if no manual layout has
been done. This avoids doing a pointless double layout (once with default
when loading the document, then with the manual layout call with the
desired layout options).
|
|
Fixes bug 695909.
|
|
|
|
When advancing a glyph in vertical mode, it should advance down the page.
The origin of the glyph as supplied is bottom left, not top right - allow
for this in calculations. Previously glyphs were not being collated into
spans because of this.
|
|
In vertical motion mode, when calculating bboxes we should use
horizontal rather vertical displacements from the 'axis of
movement'.
In horizontal mode, we displace by 'ascender' and 'descender'.
Those concepts don't rotate with the motion mode, so repurpose
those fields to hold bbox.x0 and bbox.x1 in vertical mode.
|
|
|
|
Just for internal use, no external interface.
|
|
Stroke segments that are horizontal or vertical get the same
antidropout treatment as filled rectangles.
|
|
This is not a complete general fix for features dropping out of
rendered line art, but merely a fix for one of the more common
cases.
When rendering rectangles (currently, specifically only those
rectangles that are actually defined as rectangles within the
path structure), if they are axis aligned, then ensure that they
always fill the subpixel line they are on.
|
|
Use a placeholder document instead - just a big red 'X'.
Supposedly lots of people use MuPDF to view the output of their TeX
documents. Sometimes the compilation of the TeX document fails, and
reload results in MuPDF closing. This should allow their window to
stay open until they fix the problem and reload again.
|
|
It has its own repo now. See http://git.ghostscript.com/?p=gsview.git
|
|
|
|
Inspired by bug 695823. Mutool can now dump the sizes and
orientations for pages within a given file.
|
|
Michael needs to be able to call pdfclean from gsview. At the moment
he's having to do this by including the pdfclean.c file into the lib
build, and then calling pdfclean_main with a faked up command line.
This isn't nice.
pdfclean.c is implemented by pdfclean_main parsing the options/filenames
out of argv and then passing the filenames/options on to a
pdfclean_clean function.
This seems like a much nicer API to offer to the world.
We therefore pull the guts of pdfclean.c (pdfclean_clean and its
subsidiary structures/functions) into pdf-clean-file.c and include
this in the library build.
This leaves pdfclean.c just as the command line parsing.
This should not affect the size of any of the resulting binaries.
|
|
If pdfinfo is invoked as:
mutool info file.pdf 1,2,3
then it will show the items found on page 1, then the items found on
pages 1 and 2, then the items shown on pages 1,2 and 3.
Fix this by clearing the data after each show operation.
|
|
They hadn't been updated with recent changes. Extract the pdf page
creation code from pdf_load_page into a new static function,
pdf_new_page, and use that from both places.
|
|
When writing a pdf page, we pass page->contents to pdf_new_pdf_device.
This object is assumed to be a dictionary (stream) that can be updated
with the Length and stream contents once the page writing process has
completed.
When we are rewriting a pdf page however, this can go wrong; page->contents
can be an array of objects. Not only this, in general it would be
possible for several pages to share the same page contents (or
maybe some of the elements of a page contents array). Updating one page
should not update the others.
We therefore update pdf_page_write to always create a new page->contents
object and use that.
Thanks to Michael Cadilhac for spotting the basic problem here.
|
|
Adopt (slightly modified) version of Kenny Lam's patch to allow
panning while zooming. This more closely matches how a web view
behaves.
|
|
Thanks to Goncalo Ferreira for spotting this.
|
|
Silly typo. Thanks to Daniel Bloemer for pointing this out.
|
|
|
|
Calling pdf_is_dict causes the file to seek. This is a bad thing
in a process that is running through the file. It's doubly bad, as
the thing it seeks to read may not be there as it might not have
been repaired yet.
So, instead of just keeping the 'most recent root that is a
dictionary', we change to keeping a list of the roots we have found
while parsing the doc. At the end we then check for the most recent
one that is a dictionary and use that.
|
|
|
|
|
|
When repairing a file we keep track of the most recent 'Root' entry
we have found. Only accept a new Root entry as a replacement if it
is a dictionary.
|
|
... and move outline printing to mutool show.
|
|
The pdfapp files live in platform/x11 for both the X11 and win32 builds.
Our curl submodule does not build cleanly on MinGW, so skip that variant.
|
|
On windows, handle mouse wheel events as mouse events rather than
keyboard ones. This means that Ctrl-wheel zooms as expected (consistent
with Chrome etc). Also ensure that Shift-wheel changes from vertical
to horizontal.
Mouse wheel over pages that are larger than fit in the window
now scroll around the page. Once they hit the edge of the window,
the page flips to the next/previous page as you would expect.
|
|
Simon Reinhardt points out that writexrefstream calls pdf_update_stream
on an object, rather than on a reference. The code as written fails to
do the update, and the updated file is broken.
I fix this here by updating pdf_update_stream to be able to work
with both objects and references. This is in contrast to his patch
which would create a reference for the sole purpose of performing
the update.
|
|
Update pdfapp_onkey to take modifiers. If shift is held down when
space is sent, then back up a page.
This involves updating the windows app to actually send modifiers.
Previously they were always sent as zero to the onmouse routine.
|
|
|
|
pdf_load_image_stream is supposed to return a buffer containing the
uncompressed stream from an object (or, in the case of image streams
where an fz_compression_params structure is supplied, a stream
decompressed up to the point of the image format compression).
We have an optimisation in pdf_load_image_stream to allow it to
return the existing buffer from a cached object rather than
reloading it again, but as bug 695549 points out, this breaks in
the case where the cached stream is compressed.
The suggested fix by the bug reporter (Stefan Klein) would work
in that it would stop compressed streams being returned as
uncompressed ones, but it is not perfect as it could lead to
several copies of shortstoppable image streams being loaded (and
for streams with null or empty array filters being mistaken for
compressed ones).
The fix here solves these cases too.
|
|
Adopt patch from Risto Saarelma. When in presentation mode, left
and right mouse buttons flip pages forward/back.
|
|
When inverting matrices, use doubles for inversion calculations. This
prevents floats over/underflowing and causing stroked content to go
missing.
|
|
Adopt Guillume Duranceau's patch to set the NET_WM_NAME property for
window titles.
|
|
If b is out of range (-ve), then this can let s == 0 and we can get
failures.
|
|
Given that MuPDFReaderView has a public setMode call, ensure that
the enum with the Mode values in is public too.
Thanks to Jeremy Dixon for pointing out the issue.
|
|
Adopt a small patch from ooesili@gmail.com to avoid zombie processes
that are left around after processes opened from PDF links are
terminated.
|
|
I can't claim to entirely understand why one formulation works and
the other doesn't, but it seems a harmless enough fix that apparently
works.
|
|
Based on changes supplied by mt-82@gmx.org, but bent to be more
in keeping.
The actual building with MINGW is untested. We merely verify that
these do not break the existing builds. With a bit of luck they
should work though.
|
|
|
|
The actual fix implemented here is to bale out of pdf_write_document
if we are updating incrementally and the file has not changed.
|
|
Adopt a (trivially modified) patch provided by Simon Reinhardt.
When loading pdf outlines, if the 'Count' field is positive, the outline
entry should be considered open.
|
|
When making a new pdf_run_processor to handle type 3 glyph contents,
we can inherit the current gstate. Do NOT inherit the current clip
depth, as otherwise we pop too many on exit.
|
|
Move pdf-write.c over to calling fz_fprintf for all places in we need
printf, and fputs elsewhere.
|