| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Remove fz_free_display_list from the API; instead use fz_drop_display_list.
|
|
|
|
|
|
When saving, we'd close the document before we save it. As part of
the leak fixing work, I'd freed the path as part of the closing
process. Rework slightly to avoid this.
|
|
Skip over successive whitespace in search string.
Make android use text_search.c
|
|
|
|
We were failing to setup and maintain the span number correctly.
|
|
Android app was still thinking that we had only one fz_device_rgb rather
than one per context.
Android app had a typo in resulting in searching ending in an infinite
loop.
Text search failed to search outside the first block of each page.
|
|
Update android build in line with text extraction structure changes.
|
|
|
|
Need to update text handling in line with new object types due
to image extraction.
|
|
Following up on a report from a potential customer, fix various places
in mupdf.c where we were leaking memory (devices not freed, context
not properly freed etc).
In order to track this down, I added a Memento build - just do:
ndk-build MEMENTO=1
when building. This only checks for leaks, not for memory overwrites
by default as it uses MEMENTO_LEAKONLY to avoid any possibility of the
android kernel killing stuff for being too slow or using too much
memory.
|
|
We renamed fz_new_output_buffer to be fz_new_output_with_buffer, and
missed the call from the Android specific source. Fixed here.
Thanks to Philippe Le Becq for the report.
|
|
Disable some features when in reflow mode
Disable features when document format prohibits
Add a few instructional on-scrren, info messages
|
|
The div/spans still use table style rendering, but it's simpler
code (and html) this way.
|
|
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.
|
|
|
|
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.
|
|
This fixes bug #693664, and also simplifies app code.
The example file attached to the bug produces strange results, but that
is because the QuadPoint information is incorrect.
|
|
Use of the bbox device to derive the area of the display list can lead
to bad results because of heuristics used to handle corners of stroked
paths.
|
|
Highlight annotations currently come out opaque so aren't a lot of use.
|
|
Also change the way we pass the text rectangles so that
non-axis-aligned ones can be permitted, and relocate the code that
calculates the strike-out lines from the bounding boxes
|
|
|
|
|
|
|
|
|
|
|
|
This gets us styles.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
Remove unnecessary hitPageLink method from MuPDFCore and extend the
handling of external links to the java classes
|
|
|
|
This solves the android build SEGVing on xps files such as
ECMA-288.xps.
|
|
|
|
Previously, we had assumed that we'd only ever have one MuPDFActivity
running at once; this meant that we only had a single MuPDFCore, and
that it was safe to hold the native libraries state in global
variables.
Unfortunately, it seems that if you launch MuPDF from the apps list,
and open a file, then return to the home screen using 'Home' rather than
'Back', MuPDF is kept running in the background. Launching a PDF file
from a file manager then starts a new MuPDFActivity and things get
very confused.
The solution implemented here is first to move all the MuPDF global
variables into a 'globals' structure, and update the code to use
this. Next, we allocate this structure on 'openFile', and free it on
'destroying'. Finally, we return the pointer to this structure as a
java long from openFile, and store it in a private data pointer,
globals.
Each MuPDFCore native method can then retrieve the value of 'globals'
and get the global state back. This means that every MuPDFCore native
method must now be non-static (except isJavascriptSupported).
|
|
|
|
|
|
Requires android-ndk-profiler to be copied into android and android/jni.
Also requires r8c of the NDK.
|
|
|
|
|
