pdf viewer for pdaxrom?

[amrein]

Well sorry. I didn't use the magic word   sorry.

Hi. Where can I download the new pdaXrom rc7 sdk please? Is it already available?

[Laze]

The current RC5 SDK will work fine with the RC6-7 ROM when its ready - feel free to start working on a better PDF viewer..

[SolarX]

http://www.inf.tu-dresden.de/~mk793652/gpdf/

That one might be a nice viewer ^
I'm not sure though, as I have never tried it. I was (still am, actually) considering trying to port it when RC7 is released (I don't really feel like building it for RC5 when RC7 is about to be released, making my effort rather useless  ).

[scoutme]

maybe we should try to port ghostview pdf viewer or similar - after acrobat it seems to be the faster.
Obviously qpdf2 would be THE fastest, but it sounds impossible to port

[badog]

qpdf from: www.gcc.com.cn
maybe be better.

[stbrock]

I certainly hope someone is in a position to work on a better pdf viewer for pdaXrom. It appears that is may be easier to add additional features to some other pdf viewer rather than fix qpdf2. Let me describe what I and I think many others see as the most important features needed in a pdf viewer beyond those in xpdf and qpdf.

In addition to speed, qpdf2 provides a text-view mode to display the text from a pdf file in a minimally formatted layout that allows the maximum amount of readable text to be viewable on the small screen. It also has some support for moving easily through the document without stylus or typing. The text-view option takes advantage of the fact that most pdf's nowadays are text-searchable by means of ASCII encoding of their text linked to the page image. I'm not aware of any Linux pdf viewer other than qpdf2 that uses this text aspect of the pdf specification, though it has been out for a good while. Another useful feature is support for adding notes and comments to particular pdf pages.

You can easily switch back to the usual pdf image to see tables and images or clarify formatting in qpdf2, but the text-view option is very fast and is sufficient a large percent of the time. Add to that some basic support for paging through the document with one hand in portrait mode using the various buttons on the side of the Zaurus and you have a very fast and useful viewer for a lot of material on the web or in private databases.

Speed and ability to render pdf's as images (at least ignoring without crashing the newer features if they can't be implemented easily) are also important, but pdf's viewed as images are never going to be that fast on current handhelds, and often the font can only be made readable by limiting viewing to a small portion of the image, making reading difficult. If you have to scroll back and forth to see a full line of text, you're in trouble. The text-view capability described above seems crucial to me to make pdf's really usable on the Zaurus.

[scoutme]

qpdf2 would be a killer app for any linux rom, I think

[g33k]

Like many of you, I agree that the PDF reader is a killer app for a handheld like the Zaurus. I have a suggestion as to how we might be able to get one:

Why not establish a bounty for the app? We could agree on the requisite features - like the ability to access embedded plaintext - and donate money towards the port / cross-compile. The first frood to submit a working IPK that does all we request gets the bounty, and we all get the app.

In fact, I think this might be the way to go for any number of apps for the Zaurus under pdaXrom. I'd quickly donate to the PDF bounty, as well as to a bounty for a good audio recorder and/or editor.

[amrein]

Well, in my experience, xpdf 3.0 support more pdf than other pdf reader on Linux. Less than acrobat reader but this one is closed source.

What is the issue with the current already included pdf reader? Crash? Bugs? Have you got a problematic pdf file that I could test? I mean something a file bad handled by xpdf.

[scoutme]

currnetly xpdf on zaurus cannot handle:

big (but not so big) pdf
lots of fonts, non correctly at least

more: it's slow, both in loading and in navigating, crashes on half the doc I try to open

Just to explain: when I were using qpdf2 on cacko I could be almost sure I would be able to read any pdf. With Xpdf ported I'm quite sure that I'll have some problem with pdfs. Actually it's better to translate'em in html docs via google. Tha funny part is that qpdf2 let you read pdfs as plain text, so it has also the google service feature, we can say


I think that lots of people would pay for a pdf viewer, but the idea must be revisited: a "bounty" will cause a lot of people writing bad software, filling the forum with useless packages.
I think we should support a defined, even if open, group of programmers , in order to obtain a good program.

If pdaXrom team would accept to organize such a group, they could activate a new support fund. Also they could distribute it as an opensource-shareware hybrid, or sell it, but I think that in the case they guarantee their will to start this project, there would be a lot of donations.

I read that someone wanted to port qpdf2 (OZ team, meybe), but desised due to the low quality of code. Well, maybe we could  balance the  expense/benefits ratio by paying them a quota, only if they start a pdf-viewer project with professional way of proceeding.

An idea: pdaxrom team could make a pdf-viewer donations fund, and then organize and pay a team for the development. If the team works as intended to, it will receive the money. If not, they won't, or not completely. In that case, since the money would remain to pdaxrom team, it would be part of usual donations, where those who paid for the pdf-viewer will be able to decide not to donate anymore until the quota they paid for the pdf viewer would be assimilated (to restabilish their donation equilibrium without feeling to have paid for something they didn't get  ).

...sorry fo my english, as usual

[ltrm]

What about a plug-in for an existing e-book reader such as Opie Reader?

I agree with stbrock that what makes qpdf particularly good is its ability to format pdfs as text.

If Opie Reader could open pdfs reliably it would be perfect for me.

[g33k]

> a "bounty" will cause a lot of people writing bad software, filling the forum with useless packages.

I respectfully disagree.

The bounty idea would require that we (the donating community) define the parameters of an acceptable app. Those parameters can be as specific and detailed as need be to ensure that the resulting packages are acceptable and useful.

(Personally, I think we'd all be better off with simpler, more direct requests - for example, by simply saying the bounty goes to whomever first ports qpdf for pdaXrom. This would be a more straightforward task and I think it would increase the likelihood that someone would actually take us up on it.)

Also, if the result of the bounty was that several new apps become available, I don't see the downside. Use the one you like. Chances are some of us will prefer one, others another. Choices are good and will broaden the appeal of pdaXrom. I don't see this as "useless."

> If pdaXrom team would accept to organize such a group, ...
> ... pdaxrom team could make a pdf-viewer donations fund, and then organize and pay a team for the development.

I don't mean to speak for them, but my thought is that the pdaXrom team have plenty to do as it is. They may choose to take on some of the work - and obviously that would be great - but I'm wary of asking them for more and more. They have a limited amount of time and energy, and I'd rather see that go into the pdaXrom distro itself - specifically into broader hardware support and more easy-to-use configuration utilities and applets.   I think software development / porting should be up to us, the community.

I'll continue to donate to the pdaXrom team, and I'm offering to donate to porters / cross-compilers / software developers as well.

[scoutme]

actually you are right: if we detail the request we reduce the possibility of low-quality answers to our needs. I only would like to see a sinergy of commonly interested people in a few defined task, more than a race. I'd like to avoid commercial-stamp conservative mechanics. That said, you're right

[ostense]

Just to explain: when I were using qpdf2 on cacko I could be almost sure I would be able to read any pdf. With Xpdf ported I'm quite sure that I'll have some problem with pdfs. Actually it's better to translate'em in html docs via google. Tha funny part is that qpdf2 let you read pdfs as plain text, so it has also the google service feature, we can say

The xpdf homepage is :
http://www.foolabs.com/xpdf/home.html

Qpdf2 is built on xpdf so it is strange that it should behave a lot better...
Also the xpdf can read pdf files as text files according to xpdf documentation:

"The Xpdf project also includes a PDF text extractor, PDF-to-PostScript converter, and various other utilities."

Rather then starting a new project  join the xpdf project and address the problems with xpdf to the project.

[SolarX]

The main thing that seems to make xpdf so incredibly slow is the fact that it loads the entire pdf to memory on startup. I think it would be more reasonable to make it cache, say, 10 pages, and load the rest in the background. If a page number is specified by the user, it should just start loading at that offset, show the page, and continue loading in the background (in a non-blocking way). This may require complex algorithms, but it seems to me that's the most efficient way to handle pdf's on these machines.

For now I've been converting pdf's to html on my desktop, which seems to work very well. I read them in Dillo, which formats it so I never have to scroll horizontally. It might be a bit more work on the desktop side, but I can imagine a html reader will be faster than any pdf reader just because of the formats.