| 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.
|
|
- 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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
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)
|
|
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.
|
|
Now use one-time allocation of page-sized bitmaps
|
|
|
|
|
|
Don't countPages until after we have a password.
|
|
|
