| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Tor observes that when advancing down a page, it's annoying to have a
tiny scroll at the end to expose the last pixel. To avoid this, he
suggests making the amount we scroll dynamic; rather than always
moving by 90% of the screen height, we allow ourselves to move between
80% and 95% of the screen height if it means that we'll exactly meet
the end of the page.
This seems to work well.
|
|
|
|
|
|
|
|
Moving backwards from the top of a zoomed out page was taking us
back to the top of the previous page, not the bottom. Fixed here.
Thanks to Tor for spotting this.
|
|
Use setImageResource instead of setBackgroundResource!
|
|
Also, replace ".." with "[Up one level]".
|
|
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.
|
|
Jarkko Poyry(*) points out that gradients are incorrectly rendered
when they aren't axis aligned. This review fixes it here using a
patch inspired by both his and zenikos patch. Thanks guys.
Further thanks to zeniko for spotting that it applies to the XPS
code too and providing a patch.
* Apologies for the lack of the accent - my editor/git gives problems
with them in commit messages.
|
|
Bug 693527 points out that we fail to spot Jpeg 2000 images that
have themselves as their own SMask and enter an infinite loop.
We extend the code by passing the forcemask parameter in exactly the
same way as the non-JPEG 2K code does.
Thanks to Jarkko Poyry for spotting this, reporting it, and suggesting
the fix.
|
|
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.
|
|
Update clipboard icons to ones that make the intent clearer (but
probably aren't as pretty as I drew them).
Resize doc items to be the same width as dir icons so the file
list looks nicer.
|
|
After much discussion and investigation, Paul and I have realised
that we do in fact (in the current scheme at least) need to hold
the existing bitmap in memory while drawing the next one (as the
existing bitmap is still in an ImageView and being used for any
foreground render requests). As such remove a 'setBm(null)' in
drawPage.
Also, in the onPostExecute for the patch redraw, we cannot recycle
the bitmap in a bitmap holder due to it still potentially being
in use. We therefore add a 'drop' method to the BitmapHolder class
that sets the reference to null without recycling. This is not
ideal, but is better than recycling too early and causing crashes.
|
|
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.
|
|
Move BitmapHolder setBm call to the main thread and after the ImageView's
setImageBitmap call.
|
|
|
|
When adding code to spot identical streams, I got the logic in
a test reversed as a result of a last minute change. Corrected here.
Thanks to zeniko for pointing this out.
|
|
|
|
When I optimised sharp edge rendering back in commit 720859d,
I made a mistake that can result in broken renderings.
Fixed here. Thanks for Dan Waleke for reporting this.
|
|
When writing pdf files, we currently have the option to remove duplicate
copies of objects; all streams are treated as being different though.
Here we add the option to spot duplicate streams too.
Based on a patch submitted by Heng Liu. Many thanks!
|
|
Simple patch to replace const char * with char *. I made the patch
myself, but I suspect it's extremely close to the one submitted
by Evgeniy A Dushistov, who reported the bug - many thanks!
|
|
This reverts commit 57c0f109b4c0d13813ca6cbc463468b503f91048
which slipped through when it should not have.
|
|
Talking to zeniko, he reports that SEGVs still occur in find_changing
within the fax decoder; he doesn't have an example that shows the
problem though (either one he can share, or one he cannot). Presumably
he has some sort of online feedback thing in the event of crashes.
Having stared at the code for a while, I see a potential problem.
I think the code may read too many bytes in the case where we
are entered with x already within the last byte of w. (i.e. where
x >= ((w-1)>>3)<<3). Fixed here.
|
|
If a PDF xref subsection is broken in the wrong place, we can get
NULL back from fz_strsep, which causes a SEGV when fed to atoi.
Add a new fz_atoi that copes with NULL to avoid this.
Problem found in a test file, 3959.pdf.SIGSEGV.ad4.3289 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
Paul had written code before to detect clicks on hyperlinks, but
we hadn't actually done anything with these clicks once detected.
Andre Ferreira supplied a couple of lines of Android magic to form
the Intent from the URL and execute it. Incorporate that here.
(Andre should have é but this upsets git/my editor, sorry)
As part of this patch, we now respond to links at a higher priority
than the left/right clicks to flip pages (but only if link following
mode is enabled).
|
|
Thanks to Andre Ferreira for bringing this up and submitting a
patch. (Andre should have é, but this upsets git/my editor, sorry!)
Change BitmapHolder handling so that we explicitly recycle bitmaps.
Old versions of Android need this to avoid bitmaps 'sticking' in
memory, and it doesn't hurt on new versions.
Also, explicitly empty the bitmap holder before creating a new
bitmap. This avoids us holding more than one copy of the (potentially
large) bitmaps.
|
|
|
|
|
|
Also invalidate search view on every select box change and
avoid creating multiple get-text tasks
|
|
although not actually do anything with the selection yet
|
|
|
|
|
|
If a colorspace refers to itself as a base, we can get an infinite
recursion and hence stack overflow. Thanks to zeniko for pointing out
that this occurs in embedded CMAPs and stitching functions. Also
solved here.
To avoid having to keep a long list of the objects we've traversed
through, extend the pdf_dict_mark functions to work on all pdf objects,
and hence rename them as pdf_obj_mark etc. Thanks to zeniko again for
feedback on this way of working.
Problem found in a test file, 3882.pdf.SIGSEGV.99.3204 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
When parsing a (broken) PDF stream, we can forget an existing
parsed object when we parse another one. Check for us having
one and free it if we do.
Problem found in a test file, 3289.pdf.asan.77.2545 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
If the Function entry does not point to either a dictionary or an
array, we should give up, otherwise we deference a NULL pointer.
Problem found in a test file, 1013.pdf.SIGSEGV.8a7.18 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
|
|
When cleaning a file with a corrupt stream in it, historically mupdf
would give up when it encountered such a stream. This is often not
what is desired, as information can be lost.
The changes herein allow us to use our best efforts when reading
a stream, so that broken streams are reproduced in the output
cleaned file.
Problem found in a test file, pdf_001/2599.pdf.asan.58.1778 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
When reading a CMAP with values out of range, we can go into a
very long loop emitting the same pair of warnings.
Spot the error case earlier and this give a nicer report.
Problem found in a test file, 3192.pdf.SIGSEGV.b0.2438 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
An unused dictionary reference could be left dangling. Simple fix
is to drop the reference after use.
Problem found in a test file, 2785.pdf.asan.6d.1985 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
Problem found in a test file, 4174.pdf.SIGSEGV.50c.3529 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
Fonts extracted from the file supplied to Werner Lemberg who fixed
the problem in freetype. Again, many thanks.
|
|
When running a softmask, we remove the softmask from the gstate,
then run the group contents, then put the softmask back.
If the gstate stack is moved in the meantime (due to it being
realloced for extension), we can end up with it being moved.
We therefore must recalculate gstate before writing again.
Problem found in a test file, pdf_001/2599.pdf.asan.58.1778 supplied
by Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google
Security Team using Address Sanitizer. Many thanks!
|
|
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!
|
|
If an OCG refers to itself, we end up recursing forever and
eventually stack overflow. Fix with the pdf_dict_mark stuff.
Problem found in 1551.pdf.SIGSEGV.7fd.615, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
With added comment to explain the funky boolean logic.
|
|
The pdf function code only expects a maximum of FZ_MAX_COLORS
component functions in a sampling function; more functions than
this causes a buffer overflow. Add some checks to avoid this.
Problem found in 1219.pdf.SIGSEGV.fc0.246, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
Two problems with tiling are fixed here.
Firstly, if the tiling bounds are huge, the 'patch' region (the region
we are writing into), can overflow, causing a SEGV due to the paint code
being very confused by pixmaps that go from just under INT_MAX to just
over INT_MIN. Fix this by checking explicitly for overflow in these
bounds.
If the tiles are stupidly huge, but the scissor is small, we can end up
looping many more times than we need to. We fix mapping the scissor
region back through the inverse transform, and intersecting this
with the pattern area.
Problem found in 4201.pdf.SIGSEGV.622.3560, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
If the key length is specified too long (0x120 for example), we can
overrun the key buffer (32 bytes). Fix this with some explicit
checks.
Problem found in 2513.pdf.asan.73.1684, a test file supplied by
Mateusz "j00ru" Jurczyk and Gynvael Coldwind of the Google Security
Team using Address Sanitizer. Many thanks!
|
|
|
