Bug 693527: Avoid JP2K images with themselves as their SMask.

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.
Bug 693520: Fix rendering of non-orthogonal gradients.

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.
Android: Implement 'Smart Motion'.

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.
Android: Show path in file picker title.

Also, replace ".." with "[Up one level]".
android: Tint the icon in the file picker.

Use setImageResource instead of setBackgroundResource!
Android: Smart Motion fix.

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.
Update copyright date.
Make strdup take a const char * to silence some warnings.
Silence some warnings.
Android: Refine Smart Motion to avoid tiny scrolls at end of pages

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.
Android: Fix NullPointerException seen on Google Play

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.
Fix dependencies in VS solution.

libmupdf, libmupdf-v8 and libmupdf-nov8 were all calling generate.bat
resulting in occasional build failures. As the latter 2 depend on the
first, only libmupdf needs call it.
Eliminate fz_bbox in favor of fz_rect everywhere.
Pass content/clip bbox to device functions by value.
Introduce fz_irect where the old fz_bbox was useful.

Inside the renderer we often deal with integer sized areas, for
pixmaps and scissoring regions. Use a new fz_irect type in these
places.
Rename fz_rect_covering_rect to fz_irect_from_rect.

It used to be called fz_bbox_covering_rect. It does exact rounding outwards
of a rect, so that the resulting irect will always cover the entire
area of the input rect.

Use fz_round_rect for fuzzy rounding where near-integer values are
rounded inwards.
Always pass value structs (rect, matrix, etc) as values not by pointer.
Rename fz_irect back to fz_bbox.
Fix Android build after rect/bbox changes.
Parts of Robin's PDF editing/page creation commit useful for annotations