| 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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
The get_globals helper function only works on non-class objects.
Hence 'MuPDFCore_javascriptSupported' can't be a static function.
|
|
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.
|
|
|
