| Age | Commit message (Collapse) | Author |
|---|
|
NoExport (and ReadOnly) fields shouldn't mark the document for saving.
|
|
|
|
|
|
|
|
rotation
|
|
Attempt to open a file that needs a password, and you will get a
dialogue box. Hit cancel on this, and the program crashes.
This is due to an attempt to release the bitmaps on a document
view that does not exist. Simple fix.
|
|
The get_globals helper function only works on non-class objects.
Hence 'MuPDFCore_javascriptSupported' can't be a static function.
|
|
Update Android build to cope with new stream implementation.
Fix a couple of typos in the android build files.
|
|
|
|
This enables us to search the source easily, without affecting the
fact that it is compiled using one.c in a single block.
|
|
Also update the code for the changes made in the stream API
|
|
|
|
|
|
Split functions out of pdf-form.c that shouldn't be there, and make
javascript initialization explicit.
|
|
|
|
New routine to filter the content streams for pages, xobjects,
type3 charprocs, patterns etc. The filtered streams are guaranteed
to be properly matched with q/Q's, and to not have changed the top
level ctm. Additionally we remove (some) repeated settings of
colors etc. This filtering can be extended to be smarter later.
The idea of this is to both repair after editing, and to leave the
streams in a form that can be easily appended to.
This is preparatory to work on Bates numbering and Watermarking.
Currently the streams produced are uncompressed.
|
|
The primary motivator for this is so that we can print floating point
values and get the full accuracy out, without having to print 1.5 as
1.5000000, and without getting 23e24 etc.
We only support %c, %f, %d, %o, %x and %s currently.
We only support the zero padding qualifier, for integers.
We do support some extensions:
%C turns values >=128 into UTF-8.
%M prints a fz_matrix.
%R prints a fz_rect.
%P prints a fz_point.
We also implement a fprintf variant on top of this to allow for
consistent results when using fz_output.
a
|
|
Previously pdf_process buffer did not understand inline images.
In order to make this work without needlessly duplicating complex code
from within pdf-op-run, the parsing of inline images has been moved to
happen in pdf-interpret.c. When the op_table entry for BI is called
it now expects the inline image to be in csi->img and the dictionary
object to be in csi->obj.
To make this work, we have had to improve the handling of inline images
in general. While non-inline images have been loaded and held in
memory in their compressed form and only decoded when required, until
now we have always loaded and decoded inline images immediately. This
has been due to the difficulty in knowing how many bytes of data to
read from the stream - we know the length of the stream once
uncompressed, but relating this to the compressed length is hard.
To cure this we introduce a new type of filter stream, a 'leecher'.
We insert a leecher stream before we build the filters required to
decode the image. We then read and discard the appropriate number
of uncompressed bytes from the filters. This pulls the compressed
data through the leecher stream, which stores it in an fz_buffer.
Thus images are now always held in their compressed forms in memory.
The pdf-op-run implementation is now trivial. The only real complexity
in the pdf-op-buffer implementation is the need to ensure that the
/Filter entry in the dictionary object matches the exact point at
which we backstopped the decompression.
|
|
Currently fz_streams have a 4K buffer within their header. The call
to read from a stream fills this buffer, resulting in more data being
pulled from any underlying stream than we might like. This causes
problems with the forthcoming 'leech' filter.
Here we simplify the fields available in the public stream header.
No specific buffer is given; simply the read and write pointers.
The underlying 'read' function is replaced by a 'next' function
that makes the next block of data available and returns the first
character of it (or EOF).
A caller to the 'next' function should supply the maximum number of
bytes that it knows it will need (possibly not now, but eventually).
This enables the underlying stream to efficiently decode just enough.
The underlying stream is free to return fewer, or a greater number
if it wants to.
The exact size of the 'block' of data returned will depend on the
filter in use and (possibly) the data therein.
Callers can get the currently available amount of data by calling
fz_available (but again should pass the maximum amount of data they know
they will need). The only time this will ever return 0 is if we have
hit EOF.
|
|
We add various facilities here, intended to allow us to efficiently
minimise the memory we use for holding cached pdf objects.
Firstly, we add the ability to 'mark' all the currently loaded objects.
Next we add the ability to 'clear the xref' - to drop all the currently
loaded objects that have no other references except the ones held by the
xref table itself.
Finally, we add the ability to 'clear the xref to the last mark' - to
drop all the currently loaded objects that have been created since the
last 'mark' operation and have no other references except the ones held
by the xref table.
We expose this to the user by adding a new device hint 'FZ_NO_CACHE'.
If set on the device, then the PDF interpreter will pdf_mark_xref before
starting and pdf_clear_xref_to_mark afterwards. Thus no additional
objects will be retained in memory after a given page is run, unless
someone else picks them up and takes a reference to them as part of
the run.
We amend our simple example app to set this device hint when loading
pages as part of a search.
|
|
Currently this knows about q/Q matching/eliding and avoiding
repeated/unneccesary color/colorspace setting.
It will also collect a dictionary of resources used by a page.
This can be extended to be cleverer in future.
|
|
Using this, we can reconstruct pdf streams out of the process
called. This will enable us to do filtering when used in
combination with future commits.
|
|
Currently the only processing we can do of PDF pages is to run
them through an fz_device. We introduce new "pdf_process"
functionality here to enable us to do more things.
We define a pdf_processor structure with a set of function
pointers in, one per PDF operator, together with functions
for processing xobjects etc. The guts of pdf_run_page_contents
and pdf_run_annot operations are then extracted to give
pdf_process_page_contents and pdf_process_annot, and the
originals implemented in terms of these.
This commit contains just one instance of a pdf_processor, namely
the "run" processor, which contains the original code refactored.
The graphical state (and device pointer) is now part of private data
to the run operator set, rather than being in pdf_csi.
|
|
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).
|
|
|
|
Change the library copying to use a system variable for the location that works in both builds
|
|
Lost as part of the accidental VS2012 change.
|
|
|
|
|
|
To share as much code as possible between the Windows 8 app, windows phone app
and Windows desktop app, remove dependencies of Platform and Windows::Foundation
in files that interface to mupdf and replace with C/C++ std methods.
|
|
|
|
We have to clean up the DirectX memory during suspension.
Also define NDEBUG for the release cases so that we avoid the use of OutputDebugStringA
in error.c which is not allowed in Windows store apps.
|
|
Under iOS 7, the slider becomes inoperable when included a toolbar
item in the standard way. Instead just add it as a subview, being careful
to also remove it to avoid multiple copies
|
|
|
|
Interaction with forms may change several pages, so all pages currently
represented by view need updating.
|
|
|
|
Otherwise, in portrait mode, there isn’t enough room for all five buttons
and some are not displayed.
|
|
The tiling in x and y is needed to ensure that we can print at high
resolutions with devices that have smaller bit map sizes (e.g. the surface).
Banding only in the y dimension like we often do is not sufficient.
Also fix an open with file association bug that must of occurred with the
transition to 8.1
And update WinRT solution for recent changes in mupdf code. This includes
the addition of a few new files and the document type registration.
|
|
|
|
|
|
Also change the way the back button works, using an explicit action, rather
than relying on the navigation controller. Doing so allowed an alert dialog to
be displayed asking if document changes should be discarded or saved.
It also allowed the word-based button to be replaced by an icon-based one,
which saves space (important for iPod and iPhone).
We may want to also save on other occasions, but this at least provides some
way to do so.
|
|
Doesn’t work in iOS 7.1: removes the the whole text view
|
|
root menu
Seems more natural and avoids cases where tapping doesn’t bring the bar back,
hence trapping the user in one of the submodes.
|
|
Use conversion assuming ascii as a fallback to assuming utf8. The library
should be converting to utf8 but doesn’t currently.
|
|
Also bring up the keyboard automatically
|
|
|
|
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).
|
|
See SumatraPDF's repo for a Windows-only implementation using WIC.
|
|
Using postOnAnimation in place of post noticably improves scroll
smoothness. Also avoid posting multiple runnables unnecessarily.
|
|
|
