| 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.
|
|
|
|
Move the platform independent java code from platform/android to
platform/java.
The plan is that we can call 'make mupdf.jar' (or 'nmake mupdf.jar')
there, and then use the resultant mupdf.jar/mupdf_native.h files in
whatever platform specific project (such as the android bindings) we
like.
Keep the android specific class (AndroidDrawDevice) in the
usual place in platform/android.
Update the android ant script to include mupdf.jar.
|
|
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.
|
|
|
|
|
|
|
|
|
|
In preparation of adding pdf_write_document that writes a document
to a fz_output stream.
|
|
Separate naming of functions that save complete files to disk
from functions that write data to streams.
|
|
Push the pointer->long and long->pointer casting through 2
static inline functions.
|
|
Less risk of confusion with the text type used in the device interface.
|
|
|
|
arrays
The list box and combo box can have values that are 2-element arrays. The first element
is the "export" value and the second element is the value that should be shown
in the list box UI. This fix ensures that we get the proper value to show in the UI.
Also, it adds the option to get the export values. These are needed if you wish to
update the field dictionary's V (value) entry, which is the currently selected values(s).
This fix works well with gsview. The other viewers will now display the proper content
in their UI, (unlike before this fix) but may need a bit more work to ensure that the
proper V (value) is updated with changes in the selections. In addition, we add
selection rectangles to the selected list box items.
|
|
|
|
- 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.
|
|
Android wants colors to be BGRA, not RGBA, so accomodate this.
|
|
Explicitly pass the page number into separation related
functions.
|
|
Get separation information out to the Java level.
|
|
If we build with DEBUG set, the native section will be built
with debugging enabled.
The debuggable flag in AndroidManifest still needs to be edited
manually, but it's set explicitly false here so we can grep for
it.
Also, send stdout/stderr to text files in DEBUG builds. The path
for this may not work on all phones (it certainly works on the
LG G3, running Lollipop), but it won't hurt on anything.
|
|
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.
|
|
Doesn't actually trigger generation from ghostscript, or load
images from files generated by ghostscript yet.
|
|
|
|
Add fz_has_permission function to fz_document.
Add fz_lookup_metadata function to fz_document.
Remove fz_meta function from fz_document.
|
|
|
|
|
|
Update android Core.mk file for html document handler, and fix a
stray fz_free_page that didn't get updated.
|
|
Purge several embedded contexts:
Remove embedded context in fz_output.
Remove embedded context in fz_stream.
Remove embedded context in fz_device.
Remove fz_rebind_stream (since it is no longer necessary).
Remove embedded context in svg_device.
Remove embedded context in XML parser.
Add ctx argument to fz_document functions.
Remove embedded context in fz_document.
Remove embedded context in pdf_document.
Remove embedded context in pdf_obj.
Make fz_page independent of fz_document in the interface.
We shouldn't need to pass the document to all functions handling a page.
If a page is tied to the source document, it's redundant; otherwise it's
just pointless.
Fix reference counting oddity in fz_new_image_from_pixmap.
|
|
Rename fz_close to fz_drop_stream.
Rename fz_close_archive to fz_drop_archive.
Rename fz_close_output to fz_drop_output.
Rename fz_free_* to fz_drop_*.
Rename pdf_free_* to pdf_drop_*.
Rename xps_free_* to xps_drop_*.
|
|
|
|
|
|
Causes a crash on Android L/ART.
|
|
Fixes opening non-PDF files from email programs that use a ContentProvider
to supply attachments.
|
|
|
|
Use intptr_t when casting between a jlong and a pointer to suppress errors
about different size words.
Add a 'u' suffix to unsigned values output by the cmap dump utility.
|
|
env/clazz pointers in globals.
The env/clazz pointers are stashed in the globals structure so that they can
be accessed by callback functions in mupdf.c (such as bufferStreamSeek()).
The intention is that only one thread (i.e. the AsyncTask background thread)
reads/writes these stashed pointers. Because cookies are created/destroyed
in the main thread, we add a new version of get_globals() which doesn't trample
these pointers.
|
|
to file and open from file works
Patch was supplied by gong_su@hotmail.com. Thanks!
|
|
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.
|
|
renders a specific PDF
Some async tasks were still trying to access the globals pointer, which had
been nulled during shutdown, leading to a crash.
Check for NULL and return cleanly in this case.
Possibly we should also be calling AsyncTask.get() to wait for the tasks to
finish, before nulling the global pointer?
|
|
|
|
This adds a custom memory management layer between libjpeg and the calling
app - in such a way that the code can be shared between mupdf and
Ghostscript/PDL.
|
|
Update Android build to cope with new stream implementation.
Fix a couple of typos in the android build files.
|
|
|
|
Split functions out of pdf-form.c that shouldn't be there, and make
javascript initialization explicit.
|
|
Patch from Thomas Fach-Pedersen. Many thanks!
Add a new format handler that copes with TIFF files. This replaces
the TIFF functionality within the image format handler, and is
better because this copes with multiple images (as one image per
page).
|
|
|
|
|
|
Only -I the config header directory if building the thirdparty library,
not if using the system library.
Fix bug 694808.
|
|
The OpenJPEG in gs is v2, with various patches for fixes. These are in
the process of being passed upstream. We now automatically pull the
openjpeg tree out of GhostPDL and put it in as one particular branch
in the thirdparty/openjpeg.git repo. Change to track this in MuPDF.
This is in keeping with what we have been doing with the jbig2dec
repo for a while now.
|
