| Age | Commit message (Collapse) | Author |
|---|
|
platform/java and platform/android are reorganized:
platform/java
The new JNI Java classes, mupdf_native.{c,h}, Makefile and Makejar.
platform/java/example
The example desktop viewer classes.
platform/android/viewer
The original demo viewer.
ndk-build is used to build libmupdf_java.so,
making reference to mupdf_native.{c,h} in platform/java.
|
|
We were converting from a File to a filename then to a Uri
using Uri.parse, but Uri.parse has problems with hash marks.
Instead convert direct from File to Uri.
|
|
|
|
The purpose of JNI bindings is to allow MuPDF to be driven from
Java. There are several possible use cases here.
Firstly, and most simply a java application can ask the core of MuPDF
to open a document and render it using the existing devices to
produce output on a standard Java bitmap.
Secondly, a java application might want to drive the device interface
itself, making use of the standard MuPDF devices (such as using the
rendering engine to render high quality graphics).
Thirdly, a java application might want to implement its own device
and then call MuPDF to run the document to that device (perhaps to do
custom text or image extraction).
The first of these cases requires a simple reflection of the main
document and standard device classes in JNI.
The second of these cases requires the actual device interface itself
to be made available as a java interface, together with the ability
to construct and manipulate data types like paths, text and fonts so
the Java code can build the required objects to pass to implementers
of the device interface.
The final case requires a reflection layer whereby calls through the
device interface in C can be turned into method calls to a Java
interface.
All of this is attempted in this commit. Some highlights:
For each type in the C (such as fz_colorspace) we have a corresponding
java class (such as ColorSpace).
Where the 'fz_' types are reference counted (such as an fz_colorspace),
the java objects (such as ColorSpace) simply take a reference to a
pointer to the underlying fz type. Java accessor methods are then
provided to manipulate these types.
Where the 'fz_' types are not reference counted (such as an fz_rect),
the data is actually contained within the Java object itself (such as
Rect, RectI and Transform).
We add a VS jni project. This doesn't do anything except make the
files accessible for editing in the IDE.
As much as possible, the Java layers do nothing (other than some
programmer friendly type overloading), construction (unavoidable,
as can't be done in JNI) and boiler-plate destruction. All the
smartness is done in the C.
Due to Java and C's differing approach to constness, we need to be
careful that a java device does not destructively alter objects
passed to it. For example, consider running a display list through
a device implemented in java. If the java device were to change a
Font object passed to it, this might affect other objects in the
display list that shared the same underlying fz_font.
Possibly we can achieve this by having an 'isConst' flag on java
objects that are created from device calls and passed to the Java
device (see the Text class, for an attempt at this currently).
This could alternatively be achieved by cloning every such
piece of data (see the path code for an example of this approach),
but this is probably slow. Better to clone 'just in time' as the
first write operation is done to the object.
|
|
- use core.fileFormat to decide whether a proof file is being viewed,
- don't show the proofing button except for PDF files.
- in a proofing activity, show the page that was being viewed when
the proof was requested.
- Add extra two arguments to fz_write_gproof_file in the Android build.
|
|
Probably related to bug 695507.
|
|
Explicitly pass the page number into separation related
functions.
|
|
Get separation information out to the Java level.
|
|
MuPDFCore now supports a gprfSupported method that returns
true iff we compiled the core with SUPPORT_GPROOF and a
libgs.so is available.
|
|
Hit the proofing button, and we create a new temporary .gproof file.
We invoke a new version of MuPDF on that. When that finishes control
returns to us, and we delete the .gproof file.
Currently the new version of MuPDF loads the .gproof file, but fails
to generate any pages from it, as we have no version of ghostscript
on the system. Generating this new ghostscript is the next job.
|
|
|
|
Adopt (slightly modified) version of Kenny Lam's patch to allow
panning while zooming. This more closely matches how a web view
behaves.
|
|
Thanks to Goncalo Ferreira for spotting this.
|
|
Given that MuPDFReaderView has a public setMode call, ensure that
the enum with the Mode values in is public too.
Thanks to Jeremy Dixon for pointing out the issue.
|
|
I can't claim to entirely understand why one formulation works and
the other doesn't, but it seems a harmless enough fix that apparently
works.
|
|
Spotted by "Pogon". The code to choose between horizontal and vertical
scrolling was broken due to a missing ! in a condition. Cut and Paste
error.
|
|
|
|
A potential customer (currently a free user) contacted us asking
that MuPDF be extended to support vertical scrolling rather than
horizontal scrolling. He supplied a partially working patch.
We reviewed his patch, and found the bit he'd missed, which he added
and it now works for his purposes. We also spotted some places
where his patch is incorrect in general though (and will go wrong
for cases where PDF files have varying page sizes).
This is a commit of a correct version. ReaderView gains a
HORIZONTAL_SCROLLING boolean that is set to true currently to
maintain the normal behaviour. Change it to false and we will
scroll vertically instead.
Possibly we could add a button to allow this to be a runtime option,
but that's a future enhancement.
|
|
Patch from Michaël Cadilhac.
Continue to pass events to panning GestureDetector when zooming (but do not
act on the reported gesture).
Previously we just stopped sending events to the GestureDetector until the
start of the next gesture.
|
|
Memory buffers are used for implementing content:// URLs, which are
(in most cases) readonly. If we ever encounter a read/write content://
URL in the future, we could consider supporting saving to it.
(An example of a content:// URI is an email attachment, where IPC is used
to transfer the file from the email client, rather than relying on a local
file).
|
|
Fixes opening non-PDF files from email programs that use a ContentProvider
to supply attachments.
|
|
On 2.3.x, opening files from the Android email app (not Gmail), was causing
a crash due to a SecurityException. On 4.x, it was failing with an error
message.
I think we should have just been calling
getContentResolver().openInputStream(uri) to get the file data, rather than
reading the row from the content resolver and looking at the _data field.
On 2.3.x querying this row caused a security error. On 4.x, we got back
a _data field containing a path, but this path was internal to the email
app, and not for our consumption.
Previously we were calling openInputStream() only as a fallback; now we try
it first, and fall back to the other method if that fails. I suspect we can
delete the other code, but I can't test on the 3.x version of the Transformer
Prime, so I'm leaving it be for now.
|
|
The GUI layout tool instantiates custom controls classes to display a
preview in the IDE. It relies on the 2-argument constructor being
implemented.
Use a different means to get the window manager that works for non-activity
contexts, and avoid creating gesture recognizers in this situation.
Based on a patch supplied by Masaki Muranaka
|
|
|
|
Fixes bug #695191 - Mupdf Build49/armv7a & Android 3.1: cycles
through subset of pages & page scrubber
The problem here was that in Honeycomb, various bitmap operations
(including drawing via JNI) do not update the bitmap generation count.
When hardware acceleration is enabled, this means that the underlying GL
layer is not aware that the bitmap has changed, and ends up reusing old
textures.
To workaround this, we erase the bitmap before drawing the page. Erase
appears to be the only operation I could find (after pouring through the
source), which actually increments the generation count. The other option
would have been to disable hardware acceleration, but that was far less ideal.
|
|
then pressing back button again.
I've also added an onCancel() handler, so that the back button only needs
to be pressed once to return to the file picker view.
Spotted while looking at bug #693719 - Attached PDF file does not display (edit)
|
|
crash when rotating the device.
When cancelling a render async task, we now wait for it to actually finish
before continuing. The benefit of this is that we should be able to guarantee
that its Bitmap becomes eligible for GC before we continue to create any
new bitmaps.
This should hopefully help with the OOM errors seen when rotating
the device and trying to create the new bitmaps.
To prevent the UI thread from being blocked for too long while we're waiting
for the async task to finish, we use a fz_cookie and set the 'abort' flag to
request the render be stopped as soon as possible.
|
|
|
|
Android sometimes calls the 'getSelectedView()' method of an AdapterView.
This can be made to happen more predicatably by enabling the Talkback
accessibility feature.
Remove the UnsupportedOperationException and just return null, as we the
ReaderView does not have the concept of a selected page.
|
|
ChoosePDFActivity can be used either to select PDF/XPS etc files,
or to select key files (for digital signatures). The choice of which
one to use is made according to the action string in the Intent with
which the activity is invoked.
Previously we would look for Intent.action.MAIN and take this to mean
"Look for PDF files", and anything else to mean look for key files.
Unfortunately, if you start the activity directly using adb then the
action string is null, so we look for key files.
The fix is to use a specific (custom) string for key files and for
everything else to be treated as a request for PDF files.
|
|
Attempt to open a file that needs a password, and you will get a
dialogue box. Hit cancel on this, and the program crashes.
This is due to an attempt to release the bitmaps on a document
view that does not exist. Simple fix.
|
|
The get_globals helper function only works on non-class objects.
Hence 'MuPDFCore_javascriptSupported' can't be a static function.
|
|
Using postOnAnimation in place of post noticably improves scroll
smoothness. Also avoid posting multiple runnables unnecessarily.
|
|
Make single-point strokes display by special casing them as
circles. Thanks for Michael Cadilhac for the suggestion.
|
|
In some cases freshly-created annotations could fail to appear because the HQ patch was
being left in place even when zoomed fully in, and when in that state, the patch was not
updated. The bug was usually hidden by an onLayout call being triggered with an out-
of-date patch, which causes the HQ patch to be removed. The bug is fixed by having
addHq remove the patch when fully zoomed out. Since now addHq may sometimes add
the patch and sometimes remove it, I've renamed it to updateHq.
Correctness of this fix has not been checked because I was unable to trigger the bad
behaviour on my test device.
|
|
While scrolling, avoid some overheads to do with image scaling that
need updating only on a zoom-level change
Remove a pointless invalidate call.
Avoid calls to removeViewInLayout and removeAllViewsInLayout that
were being made in functions not called from onLayout
|
|
Thanks to Dale King for reporting this.
|
|
Also fix a race condition where an attempt to set the zoom might precede
the loading of html into the WebView
|
|
Now use one-time allocation of page-sized bitmaps
|
|
|
|
|
|
If there is no text to select we return an array with a NULL in it
and this causes the code to crash. Simple workaround.
|
|
Don't countPages until after we have a password.
|
|
|
