| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
|
|
|
|
Update fz_text_analysis function to look for 'regions'; use this to
spot columns etc. Spot columns/width/alignment info.
"Intelligently" merge lines based on this.
Update html output to make use of this extra information.
|
|
If a line starts with a recognised unicode bullet char, then split
the paragraph there. Don't use this lines separation from the previous
line to determine paragraph line step.
Also attempt to spot numbered list items (digits or roman numerals).
The digits/roman numerals code is disabled by default, as while it
worked, later commits made it less useful - but it may be worth
reinstating later.
|
|
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.
|
|
|
|
|
|
Don't subtract the itemsize on error when we haven't added it
yet.
|
|
When we calculate the bbox to store in display list nodes, we had been
forgetting to allow for the stroke state.
|
|
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.
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
Thanks to Brian Nixon for pointing this out.
|
|
I'd half finished this code before, and only spotted the missing
bits while cleaning up some warnings.
|
|
Some -Wshadow ones, plus some 'set but not used' ones.
|
|
|
|
|
|
Ensure pointer is non NULL before dereferencing.
|
|
|
|
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 requires a slight change to the device interface.
Callers that use fz_begin_tile will see no change (and no caching
will be done). We add a new fz_begin_tile_id function that takes an
extra 'id' parameter, and returns 0 or 1. If the id is 0 then the
function behaves exactly as fz_being_tile does, and always returns 0.
The PDF and XPS code continues to call the old (uncached) version.
The display list code however generates a unique id for every
BEGIN_TILE node, and passes this in.
If the id is non zero, then it is taken to be a unique identifier
for this tile; the implementer of the fz_begin_tile_id entry point
can choose to use this to implement caching. If it chooses to ignore
the id (and do no caching), it returns 0.
If the device implements caching, then it can check on entry for a
previously rendered tile with the appropriate matrix and a matching id.
If it finds one, then it returns 1. It is the callers responsibility
to then skip over all the device calls that would usually happen to
render the tiles (i.e. to skip forward to the matching 'END_TILE'
operation).
|
|
The font bbox is wrong in some fonts, so any calculations we base
on that will be wrong; in particular this affects fz_bound_glyph.
We now spot an illegal bbox, and use a 'large' default.
|
|
|
|
|
|
|
|
|
|
Starting with 61c1f80d36bf1d946ce26d39f9afb99897fc9923 mupdf requires
pkg-config to build. However pkg-config is not supplied with Xcode
and is therefore not routinely installed on Mac OS X. Even if
pkg-config were available it would not accomplish the goal of that
commit (speed up compilation); on Mac OS X compilation would be
slower.
|
|
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.
|
|
Seen with the test file from bu 693677. When we read a file in, we
read the trailer, and the encrypt object before we start to decrypt
other objects. These objects do not make it into the xref table though.
When we write a file out, we run through the file reading in objects
prior to writing them out; when we read in the trailer and the encrypt
object we therefore try to decrypt them, giving errors.
To avoid these errors, put the trailer and the encrypt object into the
xref table when they are first read.
This solves all but 1 problem when cleaning this file with "-dif" (as
the signature object contains a digest block of data that is unencrypted).
This solves all but 3 problems when cleaning this file with "-difggg";
the signature object, and one orphan copy of the crypt dictionary that
is reported twice.
|
|
The recent positioning fix for bug 693640 caused a problem with rotated
images. The fix is to only apply the previous fix when we have rectilinear
scalings of images.
|
|
|
|
When running under Windows, replace fopen with our own fopen_utf8
that converts from utf8 to unicode before calling the unicode
version of fopen.
|
|
Due to an unfixed FIXME, the Outline details were always being detected
as being free and hence dropped.
Solve this, ensuring they go into the right part of the file. Also
ensure that Names and Dests go into the final section too.
|
|
My previous JPX softmask commit was forcing fz_alpha_to_gray to be
called with luminosity = 0, which meant it ended up with solid pixels.
This fix actually reverts the line to what it was before (but not
the rest of the commit). hivemind.pdf is still far from rendering
correctly though.
|
|
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.
|
|
|
|
Also, in the app, protect against exceptions thrown due to unknown
annotation types.
|
|
In the MUBUSY -> MUTOOL rename, one was missed.
Thanks to Michael Weber.
|
|
Use $(shell xxxx) rather than `xxxx` for pkg-config lines to avoid
repeated reevaluation. Also get X libs from pkg-config too.
Thanks to Michael Weber.
|
|
If the colorspace given in the dictionary of a JPX image differs from
the colorspace given in the image itself, decode to the native image
format, then convert.
This goes a long way towards fixing "1439 - color softmask fails to
draw jpx image.pdf" (aka hivemind.pdf). The lack of transfer function
support hopefully explains the rest.
|
|
Convert the unicode argv to utf8, and pass in to our existing main
function.
|
