[poppler] Poppler in android via JNI

[Arthur Peters]

Response interlaced.
-Arthur


On Fri, Nov 13, 2009 at 1:15 PM, Albert Astals Cid <aacid at kde.org> wrote:

> A Divendres, 13 de novembre de 2009, Arthur Peters va escriure:
> > So I want to use my android phone as an ebook reader and all the PDF
> >  viewers for the platform seem to suck badly. So I want to port poppler
> and
> >  write a simple front end for it.
> >
> > I have seen that this has been thought about ("Java/JNI-based frontend
> for
> > Android" in TODO) however I see no technical discussion. I want to start
> > such a discussion so that I can get some guidance from people who know
> > poppler better. The questions I can think of now are:
> >
> > * Should I just render the PDF down to a bitmap in C and then pass that
> to
> > Java and draw it to the screen (basically just modify the
> ImageOutputDev)?
> > Or should I try to use the android native drawing functions to draw the
> > lines and glyphs and stuff? (or even use GLES from C)
>
> Doing a Java/AndroidOutputDev is probably better but much more difficult
> than
> just using the output of SplashOutputDev or CairoOutputDev (provided you
> have
> the dependencies for those in Android)
>

OK. I could in theory build Cairo for Android, but I'd rather not. It looked
to me like ImageOutputDev from the utils directory could create bitmaps
without many dependencies. Am I missing something?

I think that a Java output device might well be a problem performance-wise.
JNI calls are usually very slow (though I don't know for sure about Delvik)
so having lots of calls in and out of C would slow things down. But using
GLES would allow direct C calls and possible hardware acceleration and it
would mean that C would not have to call back to java (which is really ugly
in JNI). So that might be a good route. And I do know some OpenGL so that
might be something I could pull off. I don't know for sure. It would however
be Android specific where as a system that calls back into Java for the
drawing would be portable to any JVM environement at least in theory.


> > * What sort of API design should be used? Should it be something as
> simple
> > as:
> >
> > class PDFRenderer {
> >    public PDFRenderer(File file);
> >    /// The returned byte[] contains RGB(A?) values for each pixel.
> >    public byte[] renderSection(byte[] image, int page, double hDPI,
> double
> > vDPI, int rotate, int sliceX, int sliceY, int sliceW, int sliceH);
> >    public void close();
> > }
>
> You could try to mimic the glib or qt APIs, the Qt docu is online at
> http://people.freedesktop.org/~aacid/docs/qt4/<http://people.freedesktop.org/%7Eaacid/docs/qt4/>the glib one is in the tarball.
>

OK I'll look at those. I think I will go for a much simpler API at first at
least. I want to get something up and running as soon as I can to see how
poppler will perform on the low-power CPUs and so I can have a PDF reader.
;-)


>
> > * Are you interested in patches adding this feature to the main
> repository?
> If you volunteer to maintain it and it's of enough quality, of course.
>

OK we'll see what happens. I don't promise anything now, but maybe if I can
get it working I will decide that I will be up for maintaining it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/poppler/attachments/20091113/d486d2ec/attachment.html