Sunday, 22 January 2012

PDFZ, mupdf

Cut a long story short: i've come up with a simple binding to mupdf for Java.

I was going to just use jmupdf, but on closer inspection it had some issues I wasn't comfortable with. By writing my own it let me use the development version of mupdf: which has support for multiple threads and so on, and so removes the need for some of the work that had been done in jmupdf to 'libaryise' it. All I needed to do to mupdf was add -fPIC to CFLAGS so I could build a shared library out of the jni plugin.

Rather than bind the whole api (it's huge), i've bound a minimum required to load pdfs for display. A helper class written in C hides some of the mucking about when loading and rendering pages.

Obviously one thing that got me started on this was for a pdf viewer on the kobo touch ... although i'm not really convinced the display has enough resolution for it to work that well. I tried the built-in pdf viewer but it's pretty tedious to use - you can't turn pages unless you're fully zoomed out, and with the file I was testing it had the bounding box wrong so you had to do a lot of zoom in/out just to be able to read anything. Panning on the e-ink is a bit nasty too.

I haven't tried running it yet on the kobo: but i've already built the binaries using a cross-compilation environment so hopefully it should 'just work'. I've also made some progress on a GadgetZ based implementation, but it's super rough, here's a screenshot of it running on my workstation in my 'emulator'. I've upped the gamma somewhat in preparation for the e-ink and to test that functionality (which is why it is so dark).

I'm going to try to see if i can render the display list real-time, and only keep a frame-buffer sized backing for it. It's fast enough on the desktop, but i'm not sure about the ARM cpu on the kobo when it comes to panning (at the zoom setting shown in the picture it's taking about 0.002-0.004s to render on my workstation ... so it should be fast enough!).

The user interface with a single 'finger' input will be a challenge too ...

I crashed my kobo a couple of days ago whilst trying to work out suspend/resume, and spent a few wasted hours trying to activate it again after a factory reset since the windows pc I have access to suddenly decided to have it's hdd die ... so i'm a little reluctant to overuse it at the moment (although I ended up setting up the kobo application in virtualbox, should i need it again).

I've also had enough for today, so I'll look at the kobo another time.


Unknown said...

JMuPdf has been updated to use the mupdf library threading model. Mupdf had no multi-threading capabilites whicj JMuPdf tried to resolve na dit did using PThreads.

No that MUPDF has corrected the mutli-thread issue, etc JMuPdf has updated and simplified its source accordingly.

Download binaries and source at google:



NotZed said...

Ok thanks for the update Pedro. I figured you would update based on the changes to mupdf, but I wasn't sure on the timeline.