| Age | Commit message (Collapse) | Author |
|---|
|
|
|
1) Check before attempting to perform a partion update that the
current view area corresponds to the recorded one. Otherwise the
held bitmap will not be suitable for the basis of an update
2) When performing a complete update, reallocate the bitmap holder
to avoid risk of another task (possibly drawing for a different area)
interacting with the about-to-be-started task.
|
|
The page number was being cached at two levels, and some calls
were skipping the upper level, leaving it out of date. The
fix is always to call the lower level gotoPage from the upper level.
Since the lower level caches, there is little to gain in avoiding
the call, in any case.
|
|
Also add more detail to debug output
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
It still takes a long time to render all the queued up page requests,
but the app no longer force closes due to a NullPointerException.
|
|
|
|
Previously files downloaded/pushed while the app was running were not
added to the list when resuming the application, it had to be restarted.
|
|
* Add unpack commands for Linux.
* Specify that API level 11 is required to build.
* Describe how to get the thirdparty package using git submodule.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Also add a function to report whether the core has javascript support,
so that the additional features can be enabled only when the javascript
engine is present
|
|
|
|
Files had been added to project, but not to android makefiles.
Thirdparty file paths needed updating in android makefiles.
Rebuilding with the latest ndk (r8b) shows a problem due to a
bug in the NDK. Work around this.
|
|
If the user rapidly changes page, many drawPage calls can be queued for
many page views, each holding a reference to a bitmap. This change ensures
that bitmap creation will be delayed until the bitmaps of other views will
be gc'able, thus fixing bug 693230: "Mupdf/android provokes out of memory
when continuously rendering pages in pdf with large images".
|
|
|
|
|
|
|
|
|
|
Just fix a typo in the xml
|
|
|
|
|
|
Now selects between displaying "Text not found" and "No further occurences found"
|
|
The highlights were unintentionally being cached between file invocations.
In fact it was possible for the highlighting from one file to appear when
opening another, even if those highlights didn't match words on the page.
That could happen if both files happened to have been last opened on a
common page (common in terms of page number).
|
|
Also change the search button to behave as a toggle.
|
|
Fixed by doubling the seekbar resolution and rounding odd positions upwards.
|
|
|
|
|
|
|
|
|
|
Make a separate constructor function that does not link in the
interpreter, so we can save space in the mubusy binary by not
including the font and cmap resources.
|
|
|
|
Thanks to Robin for the nice idea of storing the text with the search so
that we can test whether it matches the edit contents
|
|
Also ensure that starting a search closes the keyboard.
|
|
Sebras found a way of crashing the MuPDF Android app by seeking
quickly back and forth with the page seek bar. After about 30
seconds of frantically tapping either end of it, we'd force close.
Examination shows this is due to the Async task queue getting full
and throwing an exception. A simple fix is to catch the exception
and perform the same tasks in the foreground.
Testing indicates that this causes the UI to stall, but it's far
preferable to a crash.
|
|
Also update the android ReadMe.txt file to include details of this.
|
|
|
|
|
|
|
|
When building MuPDFActivity as part of a framework, the application
lifecycle is slightly different. This can mean that if an attempt
is made to open a corrupt file (that fails to open) createUI can be
called with core == null. The fix is just to check that core is
non-null.
We add this check in various places to be doubly sure.
|
|
|
