Response interlaced.<br clear="all">-Arthur<br>
<br><br><div class="gmail_quote">On Fri, Nov 13, 2009 at 1:15 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A Divendres, 13 de novembre de 2009, Arthur Peters va escriure:<br>
<div class="im">> So I want to use my android phone as an ebook reader and all the PDF<br>
> viewers for the platform seem to suck badly. So I want to port poppler and<br>
> write a simple front end for it.<br>
><br>
> I have seen that this has been thought about ("Java/JNI-based frontend for<br>
> Android" in TODO) however I see no technical discussion. I want to start<br>
> such a discussion so that I can get some guidance from people who know<br>
> poppler better. The questions I can think of now are:<br>
><br>
> * Should I just render the PDF down to a bitmap in C and then pass that to<br>
> Java and draw it to the screen (basically just modify the ImageOutputDev)?<br>
> Or should I try to use the android native drawing functions to draw the<br>
> lines and glyphs and stuff? (or even use GLES from C)<br>
<br>
</div>Doing a Java/AndroidOutputDev is probably better but much more difficult than<br>
just using the output of SplashOutputDev or CairoOutputDev (provided you have<br>
the dependencies for those in Android)<br></blockquote><div><br>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?<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> * What sort of API design should be used? Should it be something as simple<br>
> as:<br>
><br>
> class PDFRenderer {<br>
> public PDFRenderer(File file);<br>
> /// The returned byte[] contains RGB(A?) values for each pixel.<br>
> public byte[] renderSection(byte[] image, int page, double hDPI, double<br>
> vDPI, int rotate, int sliceX, int sliceY, int sliceW, int sliceH);<br>
> public void close();<br>
> }<br>
<br>
</div>You could try to mimic the glib or qt APIs, the Qt docu is online at<br>
<a href="http://people.freedesktop.org/%7Eaacid/docs/qt4/" target="_blank">http://people.freedesktop.org/~aacid/docs/qt4/</a> the glib one is in the tarball.<br></blockquote><div><br>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. ;-)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> * Are you interested in patches adding this feature to the main repository?<br>
</div>If you volunteer to maintain it and it's of enough quality, of course.<br></blockquote><div><br>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. <br>
</div></div>