| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Make it easier to do release builds.
|
|
|
|
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.
|
|
Also fix android building with latest openjpeg2.
|
|
Skip over successive whitespace in search string.
Make android use text_search.c
|
|
|
|
We have a new method of making V8 libs for android that results
in a single lib rather than 2, and works on armeabi and x86 as
well as armeabi-v7a.
|
|
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.
|
|
|
|
|
|
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.
|
|
|
