Bug 693719: Android: Catch exceptions when counting pages.

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.
Simple debug code to quantify locking times
Bug 693708: Avoid dereferencing null pointer.

Ensure pointer is non NULL before dereferencing.
Add 'void' to a function declaration.
Fix store debugging fns so that all output goes to the same file.
Squash some warnings.

Some -Wshadow ones, plus some 'set but not used' ones.
pdf_device: only output color if it's changed.

I'd half finished this code before, and only spotted the missing
bits while cleaning up some warnings.
Bug 693708: Fix unclosed XML entry in fz_trace output.

Thanks to Brian Nixon for pointing this out.
Add another input mode for drawing ink annotations
Android: warn when no text selected and avoid creating empty annotations
Support creation of Ink annotations in MuPDF library
Android: add support for Ink annotation creation
Android: remove unintentional reliance on API 9

The AsyncTask class we took from android source makes use of ArrayDeque
which in turn makes use of Deque, neither of which are available below
API 9. Fix is to take these two classes from android source also
Ensure that store bookkeeping doesn't go wrong on reinsertion.

If we find that the store already contains a copy of an object, then
we don't reinsert it. We should therefore undo the addition of the
object size that we just did.
Avoid store collisions causing unnecessary evictions.

When storing tiling bitmaps from the draw_device to the store, we
frequently hit the case where we insert tile records that are already
there. (This also happens in other cases, such as an image being decoded
simultaneously on 2 different threads, but more rarely).

In such cases, the existing code attempts to evict store contents to
bring the size down enough to fit the new object in, only to find that
it needn't have. This patch attempts to fix that behaviour.

The only way we know if an equivalent entry is in place already is to
try to place the new one; we therefore do this earlier in the store
function. If this encaching succeeds (no equivalent entry already
exists) we are safe to evict as required.

Should the eviction be incapable of removing enough from the store to
make it fit, we now need to remove the entry we just added to the hash
table.

To avoid doing a full (and potentially expensive linear probe), we
amend the hash table functions slightly. Firstly, we add a new function
fz_hash_insert_with_pos that does the insert, but returns the position
within the hashtable that the entry was inserted. Secondly, we then add
a new fz_hash_remove_fast function that takes this position as an entry.
The 'fast' removal function checks to see whether the entry is still
correct (it always should be unless we have been very unlucky with a
table rebuild, or another hashtable operation happening at the same time)
and can quickly remove the entry. If lightning has struck, it works
the old (slower) way.
Fix device node bboxes for stroked paths.

When we calculate the bbox to store in display list nodes, we had been
forgetting to allow for the stroke state.
Fix error in store exception handling code.

Don't subtract the itemsize on error when we haven't added it
yet.
Android: Popup notifications for entering/exiting reflow mode.
Android: Ensure that autorotate doesn't kick us out of reflow mode.
Rework text extraction structures.

Rework the text extraction structures - the broad strokes are similar
but we now hold more information at each stage to enable us to perform
more detailed analysis on the structure of the page.

We now hold:

  fz_text_char's (the position, ucs value, and style of each char).

  fz_text_span's (sets of chars that share the same baseline/transform,
  with no more than an expected amount of whitespace between each char).

  fz_text_line's (sets of spans that share the same baseline (more or
  less, allowing for super/subscript, but possibly with a larger than
  expected amount of whitespace).

  fz_text_block's (sets of lines that follow one another)

After fz_text_analysis is called, we hope to have fz_text_blocks split
such that each block is a paragraph.

This new implementation has the same restrictions as the current
implementation it replaces, namely that chars are only considered for
addition onto the most recent span at the moment, but this revised form
is designed to allow more easy extension, and for this restriction to
be lifted.

Also add simple paragraph splitting based on finding the most common
'line distance' in blocks.

When we add spans together to collate them into lines, we record the
'horizontal' and 'vertical' spacing between them. (Not actually
horizontal or vertical, so much as 'in the direction of writing' and
'perpendicular to the direction of writing').

The 'horizontal' value enables us to more correctly output spaces when
converting to (say) html later.

The 'vertical' value enables us to spot subscripts and superscripts etc,
as well as small changes in the baseline due to style changes. We are
careful to base the baseline comparison on the baseline for the line,
not the baseline for the previous span, as otherwise superscripts/
subscripts on the end of the line affect what we match next.

Also, we are less tolerant of vertical shifts after a large gap. This
avoids false positives where different columns just happen to almost
line up.