| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Thanks to Goncalo Ferreira(*) (aka monxalo) for this patch.
Firstly, we move our textured background off the layout and into a
style applied to MuPDFActivity. By using "windowBackground", we
avoid the default background being redrawn only to be overlaid
with ours. This cuts out one level of overdrawing.
Secondly, when drawing each PageView, the old code would render the
background for the page, then would draw the bitmap over the top of
that. While it's important to draw the background of the page before
we have a bitmap for the page, we can avoid that stage once a page
bitmap arrives.
(* apologies for not being able to put the cedilla on the 'c' in your
name, but git gives problems with top bit set chars.)
|
|
|
|
Otherwise loading calc.pdf and clicking buttons causes a null
pointer exception.
|
|
|
|
|
|
Android resolves references at class load time, so when MuPDFActivity
is loaded, it tries to resolve AnimatorInflater. This fails on a 2.2
system.
The fix is to push the code into 'SafeAnimatorInflater'. When
MuPDFActivity is loaded, SafeAnimatorInflater is resolved, but
it's not actually loaded until it's used. We never use it unless
we have at least honeycomb, hence we never try to resolve the missing
class.
|
|
|
|
|
|
|
|
Disable some features when in reflow mode
Disable features when document format prohibits
Add a few instructional on-scrren, info messages
|
|
This wont work for other than PDF documents
Also, we should save the file before printing if it has been changed
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Return 0. Check for this case when opening a PDF and give a nice dialogue.
Fix the nice dialogue code so that it doesn't crash afterwards due to
a null mSearchTask.
|
|
Highlight annotations currently come out opaque so aren't a lot of use.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
According to Google Plays automated crash detection, we get a
NullPointerException when trying to parse a null string as a
Uri.
This turns out to be caused by us trying to open a PDF attachment
from gmail. This is because MuPDF is invoked with a content:// URL
that does not have a file associated with it. Instead we can open
that URL as an InputStream.
Here we amend MuPDF to spot that case, and to open the InputStream,
suck the data into a byteArray, and then to use that to open the
file from.
|
|
Currently, when the edges of the screen are tapped, we move just
enough to bring the next/previous page onto the screen. When we
are zoomed out, this is exactly what we want. When we are zoomed
in, however, it rarely is, as 1) it doesn't allow for their being
more content on the same page that we might want to view, and 2)
it doesn't take us the the same region of the next page, but rather
to the 'nearest edge' of the next page at the same zoom.
This is particularly annoying as if we accidentally hit 'right', we
can't then hit 'left' to go back to where we were.
Smart Motion is an attempt to more neatly advance/retreat through
the document in a logical fashion.
When we are asked to 'advance', we try to advance down the page
by 90% of the screen height; this will bring the next pageful of
information into view, allowing for lines that might have been
split over the edge of the screen before. If that would take us
past the bottom of the page, we just move to the bottom of the
page.
If we are already at the bottom of the page, however, we consider
advancing to the next 'column' of content on this page (i.e. we
look to see if we have another screenful of content to the right
of this one). If we do, we move to the top of the same page, at
the top. If we don't, we move to the next page.
When we move to the next page, we always move to the top, but our
X position is chosen to match the first column of text (as calculated
from the current screen position) on the next page.
We assign the right hand side and bottom edges of the screen to
'advance', and the left and top edges to 'retreat'.
Common use cases:
* When the screen is zoomed out, left/right act precisely as they
always have.
* When the screen is zoomed in to avoid the margins of the page,
left/right jump to the next/previous pages, with the same zoom,
an improvement on the current mechanism.
* When the screen is zoomed in to view a portrait file in landscape
mode so that a line of text just fills the screen, left/right
move nicely down the page a screenful at a time, and advances to
do the same on the next page. We had no way of doing this before.
* When the page is in 2 (or more) columns, and the user zooms to
fit a single column in, advance nicely follows the flow across
multiple pages. We had no way to do this before.
|
|
ClipboardManager changed its API at Honeycomb, AnimatorInflater only
appeared at Honeycomb. Both of these are used by the clipboard code.
Add fallback code to work with the older systems on older devices.
|
|
Rather than always using 20% of the screen for the tap region
(which can be excessive and confusing on a large tablet), instead
try to use just the left/right inch.
We do this by reading the dpi of the screen. As (apparently) some
devices lie about the dpi of the screen we arrange first to always
use at least 100 pixels, and then never to use more than 1/5 of the
screen.
|
|
Due to a clash on Google Play, we need to rename the apps main
class from com.artifex.mupdf to something else. We choose
com.artifex.mupdfdemo. Any user of the code in their own app
should rename it similarly. To simplify this process we add
some macros in the C.
Various renames and lots of tedious package name editing is still
required in the Java though.
|
