OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: amrein on December 10, 2004, 07:14:22 pm
-
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?
-
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..
-
http://www.inf.tu-dresden.de/~mk793652/gpdf/ (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 ).
-
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
-
qpdf from: www.gcc.com.cn
maybe be better.
-
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.
-
qpdf2 would be a killer app for any linux rom, I think
-
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.
-
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.
-
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
-
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.
-
> 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.
-
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
-
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 (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.
-
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.
-
FYI - I've split the pdf viewer posts from the 'status update' thread, as they really belong in their own thread.
-
Thanks offroadgeek. I couldn't add any other post in the other thread without been of topic.
The xpdf crashing on pdaXrom is a memory access processor issue. This is related to the ARM processor design. Those kind or bugs are hard to find in source code, even hardder when the source code is not yours, even harder when there are a lot of memory pointer for document handling.
I'm not a gnu debugger virtuoso so the copyrigthed sentence "Soon! Keep tuned" is certainly a good one to say.
-
FYI - I've split the pdf viewer posts from the 'status update' thread, as they really belong in their own thread.
I think Laze and Sash should think about all this : did you notice how implicated we are in this rom ? You say " think about a pdf viewer", and everyone post here their own idea... I mean, that is wonderful ! Maybe you should rely on us a little bit more when you think about progs that you don't have time to work on.
I think everyone can understand you and your close team want to keep the rom itself under your own controle : it's difficult enough to have two developpers agree ! But when you think about a program that is needed, just say it !
-
Has anyone worked with compiling ghostscript for the pdaXrom? I use it at work all the time to read pdfs on my Linux box. If I have time later, I might work on it myself, but I thought I'd throw it out there as a suggestion for anyone else working on this project.
Allow me to add: As I have been using it, gs is actually being called from kghostview, part of the kde desktop, when used as a pdf viewer. But it can also be used from the command line, so a wrapper can easily be used. There is also gv and ghostview as graphical front ends.
-
offroadgeek: Thanks for splitting i haven't had the time yet..
Basically anyone is free to build a PDF reader or anything for the pdaXrom - Sash has been looking at the xpdf reader and as amrein states its basically a mem problem. Anyone who has a small (<1-2 MB) pdf file which is causing problems?
-
The xpdf crashing on pdaXrom is a memory access processor issue. This is related to the ARM processor design. Those kind or bugs are hard to find in source code, even hardder when the source code is not yours, even harder when there are a lot of memory pointer for document handling.
Yep, these problems seem likely to be caused by the unaligned memory accesses, which are not handled correctly by the ARM processor. There is a handy gcc's option to hunt down memory alignment problems such as these:
-Wcast-align
Warn whenever a pointer is cast such that the required alignment of
the target is increased. For example, warn if a "char *" is cast
to an "int *" on machines where integers can only be accessed at
two- or four-byte boundaries.
It creates much false positives, but it still is easier than just reading all the code
-
Here is what happened so far in my spare time trying to debug xpdf:
_ First, I compiled xpdf for pdaXrom using the official rc5 cross-compiler. The resulting xpdf was doing illegal memory access too while loading specific pdf file (mean killed with segmentation fault). To try to correct this, I used patches from Debian Unstable but xpdf was still segfault. Used patches from Mandrakelinux. Same thing. Used both patches . No change.
_ So I really needed to find a way to debug the application. As I didn't know gdb at all I played with it a bit on x86 PC. Loading, running, breaking, stepping, listing... used gdb graphical front-end like kdbg or ddd too. All this worked well (even if the gdbui provided with my Linux distribution gdb x86 package segfault too on x86 .
_ Back on xpdf debuging for pdaXrom. There is no gdb for arm in pdaxromsdk-1.1.0-softfloat.tar.bz2. This is a missing application for the x86 sdk. To correct this, I recompiled gdb with "./configure --target armv5tel-cacko-linux". But there is a problem with the resulting armv5tel-cacko-linux-gdb: only “target sim†(mean arm simulator) will work to debug arm program directly on x86 machine. To use this arm simulator, gdb need to load a complete pdaXrom image. This mean to recompile a kernel without specific patches at least. To use remote X11, would need to build a small filesystem with default libraries (without specific Zaurus patches), a network simulated card to be able debug remote X11 connection of xpdf or to find a way to have a simulated framebuffer... To big to do so I tryied other solutions.
_ Tried to run gdb arm coming from the rc5 feed. This is a Zaurus package (installed with “ipkg install gdbâ€). Problem: I can load and run xpdf in this Zaurus gdb version but but I didn't succeed in adding a break point. I can list the source with the list command but “break 132†“run†will just run the program straight to the end. Breakpoints are just ignored. So now I needed to debug gdb to find how to fix this issue before been able to debug xpdf. A jocke . Well, let see if I can find other solution.
_ Ok. Next, installed gdb-server from rc5 feed to do remote debuggin. The problem: gdb-server is nothing else than a shrank gdb with remote protocol capacity. Used the x86 gdb version compiled for pdaXrom and on the Zaurus the gdb-server. The gdb version doesn't match but the connection is made. This time I can't display the application source code (mean the list command doesn't work). Searched for a solution but nothing found. The debug information are not used. The Zaurus gdb handles correctly the list command but not the gdb-server with my current x86 remote gdb. Without code listing it's a bit difficult to add breakpoints and to step into C source. :/
_ Next step for this afternoon: recompile gdb and gdb-server for pdaXrom using my current gdb source code version. This way, the remote gdb-server and local gdb won't have any excuse for incompatibility. If I still have issue than... well... I will have to ask to you people if you know a gdb version that work. The jocke could have been to try to debug the Zaurus gdb-server or gdb remotely.
If someone want to play too on this, well..., there is space for everyone. I you can espect, I'm not a guru and I'm doing all this for fun (and for yours).
(the last step could be to play with asertion and printf all over the source code... but this takes more time and need)
-
Ok so:
_ No information about how to get symbols with gdbserver in default gdb info page but http://www.delorie.com/gnu/docs/gdb/gdbserver.1.html (http://www.delorie.com/gnu/docs/gdb/gdbserver.1.html) show that I needed to run the remote x86 gdb with the binary name. The binary with debug information need to be on the pc. Now I can remote debug xpdf (even if the gdb versions don't match).
_ There is a bug in the arm gdb binary provided in rc5 gdb_6.0_armv5tel.ipk. The fix exist in Linux distributions but haven't been applyied upstream (not applyied on 6.0, nor 6.1 nor 6.2). Recompiled gdb from source and now I can debug on the device too without issue. I guess this will be added to the next native Zaurus gcc package. Keep tuned © TT.
_ Well, no excuse now for not finding the xpdf bug
-
My problems with xpdf segfaulting dissappeared as i took the libfreetype.so.6.3.4 from a qpdf package instead of the libfreetype.so.6.3.7 included in pdaxrom
at least i can open the files i need for my studies
only some fonts were not displayed so i copied type1 fonts from my pc to the zaurus and edited the config file
-
Osteron,
Could you be more specific on the location you found the lib that you changed, fonts added and conf file edited? I would really like to use my zaurus on some SANS security pdfs to study for upcoming exams.. perhaps you have found what I need.
Thanks,
-Richard
-
i extracted libfreetype.so.6.3.4 from this package
http://prdownloads.sourceforge.net/qpdf2/q...rm.ipk?download (http://prdownloads.sourceforge.net/qpdf2/qpdf2_freetype-2.2.1-20040217_arm.ipk?download)
copied it to /usr/lib/ and linked libfreetype.so and libfreetype.so.6 to it
for the fonts i looked in /etc/xpdfrc and copied all displayFontT1 fonts from my pc and uncommented the lines
-
The biggest problem with PDAXROM has now been almost totally fixed. I will elaborate on the work done above, and hopefully someone with more time than I currently will make an ipk of the changes - to provide pdf viewer for all.
First of, stock xpdf 3.00.
Download libfreetype.so.6.3.4 and simlink it to libfreetype.so and libfreetype.so.6... As described above this solves all segmentation faults, loading several different sizes of pdfs up to 5.5megs (all i had handy), including graphics heavy ones.
Next, when i opened most pdfs i never had text which made it quite useless. I have not had time to completely get all the font files. A ghostscipt fonts package needs to be unpacked and the relevant type 1 font files removed.
I have found fonts with filenames such as n0210031.pfb from google and uncommented / edited the xpdfrc file in /etc to point to these new TYPE1 fonts.
This seems to provide a fully functional pdf viewer... hope it helps everyone.
I miss the text extraction functionality from the qpdf2, any ideas?
-
Glad to hear about what you got.
Do you think you could prepare an archive - a simple zip, for example - with the config file, the fonts and the library (and a small readme with the info you already wrote in the last post)?
If you cannot use the forum to share it, and you don't want to spend too much time, just send it to me, and I'll manage to send the file to those interested (I might open a new thread for collecting requests).
Let me know
scoutme
-
I am going to upload it now, give me a few minutes (noisy 28k in the country...) Got a zip file, and i also wrote a script.
-
I can't upload with either firebird or internet explorer... do i need an account? It comes up with page not displayed... will find some webspace after...
-
Here is a file which should fix xpdf for you people. It includes four fonts, courier, times, symbol and helvetica. I have been able to open many dozen files, and very quickly...
Courier and Symbol were taken from the windows directory of my windows 2000 machine. If you need more fonts, get a ghostscript fonts package and edit xpdfrc.
Extract it to any directory and exceute the following command "./runscript.sh"
That should be it. Please let me know how you get on...
Xpdf Changes (http://www.student.dcu.ie/~burmisr2/xpdfchanges.zip)
-
amazing. Now Xpdf looks like it should look: an alternative to acrobat reader.
Thank you Omega
-
thanks! ;-)
Now, go immediately to the pdaxrom tweaks post. Read the contents of the two files mentioned and i suggest you do the following. Setup the mail key as a windows key. From now on i use mail-4 for alt-f4, mail up/down for volume in xmms no matter what application i'm using... the best though is mail-m - maximise the current window (e.g. xpdf). It's fantastic.
-
not sure it qualifies as a tweak --
but one of the first things that I do is go to the input control
and blank out every one of the silkscreen assignments...
otherwise, I tend to launch tons of (random) apps.
Scott
-
Hi
I've downloaded the zip and installed
but now, when i launch Xpdf he says
Error: No display font for 'Courier-Bold'
Error: No display font for 'Courier-BoldOblique' (Tiens un francais )
...Helvetica...
...Times...
...ZapfDingbats...
and some warnings
Warning : Cannot convert string "-*-helvetica-nedium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct
and when i try to open a pdf file (small) XPdf Segfault with no other information
i'll try again after a rom reinstall, but if anyone has already been in case...
thanks in advance
-
Like Sna, I get the same display font errors. I also get:
"Warning: Cannot convert string "*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1 to type FontStruct"
Ditto for courier medium, times medium and times bold.
Bill
-
To the two previous posts... read the readme (i'm pretty sure, i said this... if not i apologise). Those fonts are all missing, because i have not included them!
I included Courier, Heletiva, Times and Symbol. Any other errors are okay and not troublesome - if you want more fonts get the files...
SNA, wmadan - did you run the script? It says it can't find the fonts (courier, times Helvetica, symbol) and it also segfaults. That suggests you didn't. Unzip the file and run the script file as described in the readme. This should create a /fontfiles directory with four files in it (the four fonts). It also links the new freetype library in place of the old one. Let me know how you get on.
-
Omega,
I did run the script and it created the /fontfiles directory and there are 4 font files there. I checked the xpdfrc config file and I see the four lines uncommented out.
Bill
-
Another update:
A couple of files loaded, but not all.
Any ideas?
-
Yet another update (I am on a mission )
I checked the symlinks and libfreetype.so and libfreetype.so.6 were linked to libfreetype.so.6.3.7, not libfreetype.so.6.3.4. I edited the symlinks manually and the two test files that caused segfaults disappeared.
So, now I have a question: Is it okay to keep 6.3.7 there, or should I remove it?
-
if you have 6.3.4 installed you can remove 6.3.7 .. because when it is linked xpdf will not work .. if it's not then it won't be used.. but the next time ldconfig runs it automatically symlinks to the newer version
if 6.3.4 is not there you should not remove 6.3.7 because X won't start without libfreetype
you can also decrease the size of the lib by stripping it.. before it was 1.3M now it's only 0.4M
i also tried to compile newer versions of libfreetype.. but 6.3.4 was the latest one which was not segfaulting
-
if you have 6.3.4 installed you can remove 6.3.7 .. because when it is linked xpdf will not work .. if it's not then it won't be used.. but the next time ldconfig runs it automatically symlinks to the newer version
if 6.3.4 is not there you should not remove 6.3.7 because X won't start without libfreetype
I'd recommend against removing 6.3.7: when I did and tried to compile something (QT3? I forget) against 6.3.4, g++ bombed, complaining that libfreetype used hardware FP where the other libs on the system used software. Switching back to 6.3.7 made g++ happy again.
My impression is that xpdf has a bug somewhere that causes it to erroneously want hardware FP, and using 6.3.4 on the Z counteracts that bug instead of fixing it. So you might want to leave 6.3.7 in /usr/lib, put 6.3.4 somewhere outside ldconfig's search path, and put a wrapper around xpdf that setenvs LD_PRELOAD=/where/you/put/libfreetype.so.6.3.4 so that 6.3.7 is what everything else still uses.
cheers
jg
-
I recompiled libfreetype by myself instead of using the file from the zip so it should be compiled using the new FP system.
freetype-2.1.5 worked without problems
-
For anyone happy with RC9 and like me unwilling to upgrade to RC10 just yet, the version of xpdf in the RC10 feed installs fine on RC9 and it seems to work very well ...
Mike.
-
Hi everyone, for those who want try another nice pdf reader, here are three package:
Evince 0.4.0 : document viewer from gnome
Poppler 0.4.2: library for render pdf's
freetype 2.1.10: I compiled a fresh freetype library, because the one which is in the current feed caused evince to crash.
Some notes about avince:
- I didn't know where to put the stock_leave-fullscrean icon in the package
- Text selection cause the full page to go blank, I saw this problem in my pc to.
Stay tuned, xchm is on the way.
Have fun and best regards
Carlos F.
P.S.: PdaxRom SDK Rocks
-
Hi everyone, for those who want try another nice pdf reader, here are three package:
Great job! One note: I would suggest you uploading these right to the unstable pdaXrom feed. Contact Laze with the desired login/password, and he would create an account for you. All the packages in unstable feed came that way.
-
There is a new version of qpdf2 on Sourceforge, the first update in two years. It is described as a cleanup and bug fix release, platform independent source. The wizards at pdaXrom and OZ gave up on porting it earlier because the code was full of messy hacks. If this new version can be compiled now for pdaXrom it would be a very significant addition to the capabilities of the device, as it had many useful features that xpdf lacks. I suspect it will take a good bit of experience to get it working and hope someone will give it a try.
-
would be really great because i am reading alot of PDFs and xpdf lacks features.
-
I would love to have the text extraction like on Cackos Qpdf reader.... it makes reading my electronic magazines pdfs so handy in the past.
-
I looked at source. Archive has 17M because it contain all objects, binaries, own copies of freetype library etc..
There is a README with info for those crazy people who want to build it which I summary in few words: "hack here, hack there, #define private public so it will build".
In other words - qpdf 2.3.0-snapshot looks like previous release - lots of hacks in includes needed etc stuff. I suspect that noone will be so crazy to try to build it for OZ (atleast not someone from OZ/OE team).
-
hrw - i agree :-)
-
Too bad. Thanks to hrw and Laze for taking a look.