| Age | Commit message (Collapse) | Author |
|---|
|
page text (one page at a time) is converted to HTML and shown in
a class that extends WebView.
|
|
- use FZ_ENABLE_GPRF everywhere
- chasing changed fz APIs in gprf-doc.c
|
|
|
|
|
|
|
|
- move UI into the "mupdf" module.
The app simply sets up a DocView and starts it with a file path.
The app can call DocView.showUI to determine whether the built-in UI
is used. The plan is for apps to be able to use the built-in UI,
or supply their own.
Also includes some rudimentary UI for show/hiding annotations, and
listing links and outlines. Just for testing JNI features.
- add toolbar and tabs at the top of the view.
- refactoring
DocView becomes DocActivityView, DocViewInner becomes DocView.
- add Pages toolbar and page list view.
make the page list a little narrower.
give the document view and the pages view separate bitmaps,
and have DocPageView implement clipping when it draws.
- fix tabbing and brace style.
- add simple text selection and highlighting.
This is still a work in progress.
- various code review items.
fix tabs and brace styles
remove function calls from loop statements
use "highlight", not "hilight"
put a few strings into resources
avoid Right Hand Drift (tm)
Rects are inclusive...exclusive for the purpose of testing limits
put "else" on a separate line
put "catch" and "finally" on separate lines
|
|
This allows compilation using older Android NDKs.
This was mistakenly omitted from commit
537a467dfd6392d70624805943ac65182ec881b4.
|
|
Apparently, if MuPDF is invoked on a content stream that
comes from a URI, then is.available() can report 0 bytes
(as there is no data buffered). Use a modified formulation
that reads as much data as possible from the stream into
a BufferedOutputStream and then makes a byte array from that.
Would be nicer if the core could actually read from the
stream directly, perhaps, but that can wait for the new JNI
based version.
Thanks to Marc K for identifying the problem and supplying
the patch.
|
|
|
|
zooming and scrolling.
|
|
|
|
|
|
|
|
|
|
fz_bound_page needs the correct 2nd argument
pdf_widget_get_type should be pdf_widget_type
|
|
|
|
|
|
Reflect API change in example viewer.
|
|
|
|
Since the removal of the begin_page device function, structured
text extraction has been unable to correctly establish the
mediabox for extracted pages.
Update the fz_new_stext_page call to take this mediabox
information. This is an API change, but hopefully most people
are calling fz_new_stext_page_from_page or
fz_new_stext_page_from_display_list which are updated here to
cope.
Update all the apps/tools to behave properly.
|
|
|
|
- uses AndroidDrawDevice for rendering
- very simple sample app
- mupdf-specific functionality in a module called "mupdf"
- N-up page display
- page rendering in a background task
Signed-off-by: fredrossperry <fredrossperry@gmail.com>
|
|
also, change SUPPORT_GPROOF to FZ_ENABLE_GPRF
|
|
This is because platform/android/example also uses the resulting shared library.
|
|
|
|
The recent js change requires a makefile tweak.
|
|
If a file cannot be saved incrementally, then don't accept that
as an option. In practise this means if someone asks to save
a file incrementally, and it was repaired, or it uses encryption
then throw an error.
Add a new function to ask if it's safe to save a file incrementally,
and use that in the appropriate places.
|
|
It seems that we can end up with a null item in MuPDFReaderView
onSingleTap. Add some simple checks to avoid this.
|
|
Need to specify that we are using alphas now.
|
|
svg: Implement graphics state stack.
svg: Use idmap for symbol and use elements.
svg: Put viewport and viewBox in state stack.
svg: Rebase to version 1.9 master.
|
|
|
|
|
|
Update description to cover the fact that we no longer need
cygwin, and to strongly suggest using the Android Studio
supplied SDK/NDKs.
|
|
|
|
Also remove redundant assignments.
Fixes http://bugs.ghostscript.com/show_bug.cgi?id=695968
|
|
Thanks to Fred Ross-Perry.
|
|
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.
|
|
jni: Various cleanups.
Fix gcc and clang warnings.
Android specific functions are guarded by HAVE_ANDROID define.
The java guts of the android stuff is removed for now, to be added back in later.
Set up a makefile and simple tests to build for desktop java.
Rerig device classes to: Device, NativeDevice, JavaDevice and DrawDevice.
Add Pixmap class.
Regularize naming.
General cleanups and abbreviate naming.
Use to_JavaClass and from_JavaClass rather than
fz_mupdf_struct_from_JavaClass and JavaClass_from_fz_mupdf_struct.
Check for exceptions thrown by java devices and path processor.
Tweak constructors and finalizers to remove the JavaDevice subclass.
Use toString when rethrowing java exceptions as fitz exceptions.
|
|
|
|
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.
|
