| Age | Commit message (Collapse) | Author |
|---|
|
Thanks to Robin for the nice idea of storing the text with the search so
that we can test whether it matches the edit contents
|
|
Also ensure that starting a search closes the keyboard.
|
|
Sebras found a way of crashing the MuPDF Android app by seeking
quickly back and forth with the page seek bar. After about 30
seconds of frantically tapping either end of it, we'd force close.
Examination shows this is due to the Async task queue getting full
and throwing an exception. A simple fix is to catch the exception
and perform the same tasks in the foreground.
Testing indicates that this causes the UI to stall, but it's far
preferable to a crash.
|
|
Also update the android ReadMe.txt file to include details of this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When building MuPDFActivity as part of a framework, the application
lifecycle is slightly different. This can mean that if an attempt
is made to open a corrupt file (that fails to open) createUI can be
called with core == null. The fix is just to check that core is
non-null.
We add this check in various places to be doubly sure.
|
|
I forgot to free the stack in the reworked page loading. Fixed
here. Thanks to Zeniko for pointing it out.
|
|
We were mapping from one enum range to another, and then using
the unmapped value.
|
|
Avoid recursion in pdf_load_page_tree_node.
Avoid recursion (most of the time) in pdf_read_xref_sections.
|
|
|
|
Use _wopen on a UTF8 -> wchar_t decoded filename to support UTF8 filenames
for win32.
|
|
Once the shape was combined with the image in the file in question
the width/height drop to be below zero. Detect this case and bale.
File rendering looks fine.
|
|
|
|
|
|
Add missing options to MuPDF usage string.
Ensure windows 'About MuPDF' box is large enough to fit the
whole of the usage string in.
|
|
Previously, we would only open files with the correct extension.
Until such time as we get file type detection by contents working
assume that any file that doesn't end in .xps or .cbz is a pdf
file.
|
|
The logic in mupdfinfo was to interpret any command line argument
that ended in .pdf or .PDF as a filename, and to treat all others
as page range specifiers.
Here we change it so that page range specifiers are (roughly) detected,
and all other entries are taken to be filenames.
This doesn't address the wider issues of spotting files by 'magic' -
this is a larger task and will be addressed post 1.0.
|
|
|
|
The test in mupdf for 'is more than one tile needed' is wrong,
as it assumes that tile bboxes start at 0. Fix that, and
everything else should work OK.
|
|
Allows us to render files with broken font hinting programs when hinting
is enabled(whether by no-AA or DynaLab detection).
Fix bug 692949.
|
|
|
|
See Bug 688655 for analysis of what we SHOULD be doing. The code changes
to do this are actually quite small.
Essentially, when we join we only draw the 'top' (or 'outer') join in a
join dependent way. The 'under' join was always joined as a bevel before
as this was easy. This produces bad effects when the lines have a
significant angle between them and a large linewidth.
The correct (i.e. matching Acrobat and others) way to work is to
join the bottom of the line via the centre point. The sole exception
to this is when drawing under beziers, as we don't want to make our
approximation-by-lines obvious.
All fixed in this patch.
|
|
Comment changes only.
|
|
If this is defined during building, we use our own sinf/cosf/atan2f
functions during shading. This is set automatically if CLUSTER is defined
too, so this should remove the cross-platform differences seen during
cluster rendering.
|
|
|
|
Use this to reintroduce "Document Properties..." in mupdf viewer.
|
|
Most of the changes mupdfclean makes to a file are purely textual
(streams are decompressed etc), but some objects can undergo changes
due to being read in, and then written out. Notably in this class
are floats. For instance, the mediabox in Bug689189.pdf contains
2125.984, which when written out with the current code gives 2125.98.
This is enough of a difference to cause rendering changes.
By upping the precision (instead of %g use, %1.9g) we get better
results; we now output 2125.9839, which is much closer (and in fact
has the same float representation when read back in).
This drastically reduces the differences between a rendering of
Bug689189.pdf and the uncompressed version, but we still have
differences - in shadings, it seems.
|
|
Restricts rendering to a sub rectangle of the supplied bbox.
|
|
In my previous commit, I forgot to initialise the variable before
using it. Thanks to Bas Weelinck for spotting this.
|
|
Bas Weelinck points out a potential problem with multiple threads
starting up at the same time, running into a race condition in
the thread debugging code. He suggests using an extra lock to
avoid this, and indeed, it would be a simple way.
I am reluctant to introduce an extra lock purely for this case
though, so I've instead reused the ALLOC lock. This has the advantage
of us not having to take the lock except in the 'first call with a
new context' case.
|
|
When cloning, ensure the locks are done on the new context, not the
old one; this makes no difference except to suppress some spurious
debugging messages.
Also ensure that DEBUG is predefined for Makefile based debug and memento
builds.
Thanks to Bas Weelinck.
|
|
If compiled with -DDEBUG, cmapdump throws a large number of warnings
regarding thread locking. These are harmless and can be ignored, but
are, nonetheless, not pretty. Fixed here.
Thanks to Bas Weelinck for the report.
|
|
|
|
Currently the colorspace is selected on detecting -g, but may
then be overridden based on the filename; the -g option should
be given priority so the fix is simply to move the check for
-g down a few lines.
Thanks to James Cloos for spotting the problem and suggesting
the fix.
|
|
Don't reset the size of arrays until we have successfully resized them.
|
|
Depending on the operation used (< or <=) the threshold array should
never have either 0 and ff in it. As we are using <, it should never
have 0 in it. Fixed here.
|
|
While debugging Bug 692943, I spotted a case where we can attempt to
unlock the file while we don't hold the file lock due to an error
being thrown while we momentarily drop that lock. Simple solution
is to add a new fz_try()/fz_catch() to retake the lock in such
an error circumstance.
|
|
Put the logf call in it's own statement to fix a stupid header file
bug.
|
|
|
|
|
|
|
|
|
|
The link support still has several outstanding issues that need to be
solved.
|
|
|
