| Age | Commit message (Collapse) | Author |
|---|
|
Now can open jpeg/png/tiff files within mupdf.
|
|
One for the raw span extraction pass, one for paragraph sorting,
and another for HTML output.
|
|
Need to update text handling in line with new object types due
to image extraction.
|
|
Eventually I will get this right.
|
|
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.
|
|
V8_OK needs to be set before the includes. LOCAL_LDLIBS need to be set
after them.
|
|
In order to be able to output images (either in the pdfwrite device or
in the html conversion), we need to be able to get to the original
compressed data stream (or else we're going to end up recompressing
images). To do that, we need to expose all of the contents of pdf_image
into fz_image, so it makes sense to just amalgamate the two.
This has knock on effects for the creation of indexed colorspaces,
requiring some of that logic to be moved.
Also, we need to make xps use the same structures; this means pushing
PNG and TIFF support into the decoding code. Also we need to be able
to load just the headers from PNG/TIFF/JPEGs as xps doesn't include
dimension/resolution information.
Also, separate out all the fz_image stuff into fitz/res_image.c rather
than having it in res_pixmap.
|
|
Until someone can get me v8 libs that work on armeabi at least!
|
|
Disable some features when in reflow mode
Disable features when document format prohibits
Add a few instructional on-scrren, info messages
|
|
Implementations remain unexposed, but this means we can safely
pass functions in shades without having to 'sample' them (though
we may still choose to do this for speed).
|
|
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.
|
|
We could do with non arm builds of v8 to go with these.
|
|
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.
|
|
Various functions in the code output to FILE *, when there are times
we'd like them to output to other things, such as fz_buffers.
Add an fz_output type, together with fz_printf to allow things to
output to this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
Missed from previous commit.
|
|
|
|
By manually inserting a literal pool, we can avoid the need to
split draw_simple_scale.c out.
|
|
Forgot to add a new file to git.
|
|
Requires android-ndk-profiler to be copied into android and android/jni.
Also requires r8c of the NDK.
|
