Build Abiword 2.4.4

[daniel3000]

I have updated freetype to the latest .10 release and abiword does not crash anymore when saving as pdf
the document is still scrambled, but I will recompile poppler and abiword against the new freetype version and see if that fixes it. we will just have to wait and see now
[div align=\"right\"][a href=\"index.php?act=findpost&pid=125821\"][{POST_SNAPBACK}][/a][/div]

I'm very curious!
Creating PDF documents on the zaurus is one thing which I'd really need, not even TextMaker is able to do so.
This, and a good version of gnumeric (in rootless mode ;-) for my book keeping, would be THE killer applications to me, which I'd pay for if they work well.

It is amazing how you manage to do all that, probably besides another full-time job? Great! Thanks a lot!

daniel

[Meanie]

I have updated freetype to the latest .10 release and abiword does not crash anymore when saving as pdf
the document is still scrambled, but I will recompile poppler and abiword against the new freetype version and see if that fixes it. we will just have to wait and see now
[div align=\"right\"][a href=\"index.php?act=findpost&pid=125821\"][{POST_SNAPBACK}][/a][/div]

I'm very curious!
Creating PDF documents on the zaurus is one thing which I'd really need, not even TextMaker is able to do so.
This, and a good version of gnumeric (in rootless mode ;-) for my book keeping, would be THE killer applications to me, which I'd pay for if they work well.

It is amazing how you manage to do all that, probably besides another full-time job? Great! Thanks a lot!

daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=125840\"][{POST_SNAPBACK}][/a][/div]

openoffice could always create pdf files so this feature has been available on the zaurus and is nothing new really.
gnumeric in rootless mode works, i just fear you dont really understand what rootless mode means but we can discuss that in the appropriate sub forum.

and yeah, i do have a fulltime job working 10 hrs a day to pay the bills. i just have my zauri setting next to me compiling stuff while I am working

anyway, back to topic. pdf export/print is still not working. it seems abiword isnt actually doing the conversion and only has a stub framewoek. i am trying to build again with ghostscript installed.

[daniel3000]

openoffice could always create pdf files so this feature has been available on the zaurus and is nothing new really.

Yes, I know. But Openoffice is not usable on the Zaurus in my opinion.
Much too long startup time and not responding in time when writing. Much too inconvenient to really use it for daily work.

gnumeric in rootless mode works, i just fear you dont really understand what rootless mode means but we can discuss that in the appropriate sub forum.

Well, before moving that into another forum, let me just ask shortly: Doesn't it simply mean that no entire X/QT environment has to be started but that something like a runtime-X/QT is loaded with the actual program?

At least I know something like that from almost 10 years ago when I used Winword and Excel on a HP 200LX (MS-DOS) palmtop with a runtime-Windows-3.0 environment (without really loading the entire Windows). Was quite funny, and it worked well.
Not that it was called "rootless mode" back then, but it seems to be basically the same.

and yeah, i do have a fulltime job working 10 hrs a day to pay the bills. i just have my zauri setting next to me compiling stuff while I am working

I wish I had a job where I could do that easily. Too much colleagues and bosses in the same room here ;-)

anyway, back to topic. pdf export/print is still not working. it seems abiword isnt actually doing the conversion and only has a stub framewoek. i am trying to build again with ghostscript installed.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=125911\"][{POST_SNAPBACK}][/a][/div]

Thanks for all your efforts, Meanie!

daniel

[Meanie]

openoffice could always create pdf files so this feature has been available on the zaurus and is nothing new really.

Yes, I know. But Openoffice is not usable on the Zaurus in my opinion.
Much too long startup time and not responding in time when writing. Much too inconvenient to really use it for daily work.

gnumeric in rootless mode works, i just fear you dont really understand what rootless mode means but we can discuss that in the appropriate sub forum.

Well, before moving that into another forum, let me just ask shortly: Doesn't it simply mean that no entire X/QT environment has to be started but that something like a runtime-X/QT is loaded with the actual program?

At least I know something like that from almost 10 years ago when I used Winword and Excel on a HP 200LX (MS-DOS) palmtop with a runtime-Windows-3.0 environment (without really loading the entire Windows). Was quite funny, and it worked well.
Not that it was called "rootless mode" back then, but it seems to be basically the same.

and yeah, i do have a fulltime job working 10 hrs a day to pay the bills. i just have my zauri setting next to me compiling stuff while I am working

I wish I had a job where I could do that easily. Too much colleagues and bosses in the same room here ;-)

anyway, back to topic. pdf export/print is still not working. it seems abiword isnt actually doing the conversion and only has a stub framewoek. i am trying to build again with ghostscript installed.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=125911\"][{POST_SNAPBACK}][/a][/div]

Thanks for all your efforts, Meanie!

daniel
[div align=\"right\"][a href=\"index.php?act=findpost&pid=126048\"][{POST_SNAPBACK}][/a][/div]

yes, you are right about only running xqt runtime would be called rootless mode, however, xqt only implements experimental pseudo rootless mode, so it is not exactly the same but i have not figured out how much of the rootless thing is implmented/emulated yet, although it looks like it works appearance wise. well, i guess someone will need to do a lot of testing  do you wanna volunteer?

on another note, I believe that the pdf printing problem is not caused by abiword. but rather by libgnomeprint which does not seem to be implemented correctly, ie they seem to have hacked the size of the paper to correspond to the size of the screen which on the Z will result in garbage

[ShiroiKuma]

yes, you are right about only running xqt runtime would be called rootless mode, however, xqt only implements experimental pseudo rootless mode, so it is not exactly the same but i have not figured out how much of the rootless thing is implmented/emulated yet, although it looks like it works appearance wise. well, i guess someone will need to do a lot of testing  do you wanna volunteer?

I will gladly test it. Tell me what's necessary... and off we go.

[Meanie]

ok back to topic.

I did some more investigation and now am pretty sure that the pdf printing problem is caused by libgnomeprint and libgnomeprintui and not abiword since abiword is just using those libraries. i was able to directly generate ps document using abiword's command line invocation: abiword --print=output.ps test.txt and then I was able to convert the ps file to pdf using ghostscript, ie ps2pdf output.ps and the resulting pdf file was displaying correctly when viewed with xpdf. when i print to ps using libgnomeui, ie printing via abiword print dialog, the generated ps file is garbage and thus when converting it to pdf the result is also garbled.
so my conclusion is that abiword is fine now, but libgnomeprint libraries need fixing.

oh gosh, i just noticed, this was my 1000th posting

[daniel3000]

yes, you are right about only running xqt runtime would be called rootless mode, however, xqt only implements experimental pseudo rootless mode, so it is not exactly the same but i have not figured out how much of the rootless thing is implmented/emulated yet, although it looks like it works appearance wise. well, i guess someone will need to do a lot of testing  do you wanna volunteer?

I would gladly test it, but on another thread the discussion seems to show that it does not work yet on Cacko ROM at all due to some glibc problems.
So I guess I have to wait until these problems are sorted out.
Or does it work on Cacko for some people? Then I'd begin to test it right away :-)

daniel

[desertrat]

i was able to directly generate ps document using abiword's command line invocation: abiword --print=output.ps test.txt and then I was able to convert the ps file to pdf using ghostscript, ie ps2pdf output.ps and the resulting pdf file was displaying correctly when viewed with xpdf. when i print to ps using libgnomeui, ie printing via abiword print dialog, the generated ps file is garbage and thus when converting it to pdf the result is also garbled.

What's the difference between invoking print from the command line and from the gui?

so my conclusion is that abiword is fine now, but libgnomeprint libraries need fixing.

Seeing as gnumeric doesn't print properly (to PDF) either that would sound about right

on another note, I believe that the pdf printing problem is not caused by abiword. but rather by libgnomeprint which does not seem to be implemented correctly, ie they seem to have hacked the size of the paper to correspond to the size of the screen which on the Z will result in garbage

Is this peculiar to pdaxrom's version of libgnomeprint or something that also manifests in the upstream version? And more importantly do you think you can fix it?  

-- cheers

[desertrat]

I note that you've compiled poppler with libjpeg support. Where can I get my grubby hands on the header and static lib for libjpeg? I tried compiling my own but failed miserably because the source is so old and apparently it knows nothing about ARMs.

I used the same source but I configured with --enable-static --enable-shared options and then stole the generated libtool from poppler and hacked it for jpeg6b
also hacked the .pc file for poppler to create a libjpeg.pc file but poppler does not detect it. the configure in abiword found the new libjpeg.pc and compiled jpeg plugin without problems but poppler was a bitch and i had to hack poppler's configure script and to manually add in the correct settings so it would detect libjpeg properly and compile build it with jpeg support

I have found that simply copying the libjpeg header files ...

Code: [Select]

cp -a jconfig.h /usr/include
cp -a jpeglib.h /usr/include
cp -a jmorecfg.h /usr/include
cp -a jerror.h /usr/include
cp -a jpegint.h /usr/include... works -- at least I was able to php's gd module with jpeg support.

-- cheers

[Meanie]

i was able to directly generate ps document using abiword's command line invocation: abiword --print=output.ps test.txt and then I was able to convert the ps file to pdf using ghostscript, ie ps2pdf output.ps and the resulting pdf file was displaying correctly when viewed with xpdf. when i print to ps using libgnomeui, ie printing via abiword print dialog, the generated ps file is garbage and thus when converting it to pdf the result is also garbled.

What's the difference between invoking print from the command line and from the gui?

so my conclusion is that abiword is fine now, but libgnomeprint libraries need fixing.

Seeing as gnumeric doesn't print properly (to PDF) either that would sound about right

on another note, I believe that the pdf printing problem is not caused by abiword. but rather by libgnomeprint which does not seem to be implemented correctly, ie they seem to have hacked the size of the paper to correspond to the size of the screen which on the Z will result in garbage

Is this peculiar to pdaxrom's version of libgnomeprint or something that also manifests in the upstream version? And more importantly do you think you can fix it?  

-- cheers
[div align=\"right\"][a href=\"index.php?act=findpost&pid=126146\"][{POST_SNAPBACK}][/a][/div]

well, I recompiled libgnomeprint and libgnomeprintui and got it working, well sorta. It depends on the font I use. If I use Bitstream Vera fonts,   the PDF file is perfect. Other fonts have some characters mangled.  It's probably a font config problem since the PDF module in libgnomeprint only recognises TTF and Type1 fonts so the font.scale, etc... may need to be looked at.

[desertrat]

well, I recompiled libgnomeprint and libgnomeprintui and got it working, well sorta. It depends on the font I use. If I use Bitstream Vera fonts,   the PDF file is perfect. Other fonts have some characters mangled.

By "other fonts" do you mean non-TTF? ...

It's probably a font config problem since the PDF module in libgnomeprint only recognises TTF and Type1 fonts so the font.scale, etc... may need to be looked at.

... if print to PDF "only" works when using TTF fonts then that's no big handicap, I can't imagine why anyone would want to use bitmap fonts anyway

Anywhere we could download the recompiled libgnomeprint and libgnomeprintui?

-- cheers

[Meanie]

well, I recompiled libgnomeprint and libgnomeprintui and got it working, well sorta. It depends on the font I use. If I use Bitstream Vera fonts,   the PDF file is perfect. Other fonts have some characters mangled.

By "other fonts" do you mean non-TTF? ...

It's probably a font config problem since the PDF module in libgnomeprint only recognises TTF and Type1 fonts so the font.scale, etc... may need to be looked at.

... if print to PDF "only" works when using TTF fonts then that's no big handicap, I can't imagine why anyone would want to use bitmap fonts anyway

Anywhere we could download the recompiled libgnomeprint and libgnomeprintui?

-- cheers
[div align=\"right\"][a href=\"index.php?act=findpost&pid=126692\"][{POST_SNAPBACK}][/a][/div]

I finally figured out the root of the problem. It is a font config problem.

Abiword can display TTF and maybe Type1 (pfa/pfb) fonts. When printing, the gnome sub system that converts the content to postscript and pdf needs to convert the fonts to Type1 using the available encodings and glyphs. This requires a valid fonts.dir and encodings.dir file for the Type1 fonts. TTF fonts dont need those config files, however, the converted Type1 fonts need them so converting TTF fonts without those config files to Type1 fonts confuses that sub system. Abiword has a ttftool to do the font conversion, but the required font config files are usually missing since TTF fonts dont need them
The other problem is that xpdf needs the same Type1 fonts to display the text.
So, if you have a font that is availale in boths formats, TTF and Type1 with the font config files, then when you print to pdf, it will display correctly in xpdf.
But, if you copy the pdf file to a windows machine which usually have tons of fonts, chances are that it will display correctly in acrobat reader.
Now there is this fonts.alias file and if mapped correctly, you can alias the missing fonts and a substitute font will be used instead so it looks a bit different than the original but something readable is displayed.
Now I don't understand the format of these config files yet, maybe someone else knows. There are also tools to generate those config files like ttmkdir and ttfttool but I was unable to compile them for the Z. maybe someone with a linux machine and those tools can generate those config files.
as for the libgnome libraries, i am now not sure whether they actually need to be recompiled. maybe just fixing the font config files is sufficient. maybe they need recompiling to make the pdf files readable on the Zaurus itself but the generated pdf files seem to be ok if viewed on a PC.

[desertrat]

I finally figured out the root of the problem. It is a font config problem.

Thanks for taking the time to diagnose the problem. However I'm not sure I quite follow your explanation  

Anyway to cut to the chase, I've been trying to get PDF output via a roundabout way. Basically I compiled ghostscript and used its ps2pdf to create the pdfs. And the good thing is that there is no need to mess around with Type1 fonts. I only have TTF versions of the fonts that I use, and within each of Abiword, Gnumeric, Inkscape, I "printed" to a ps file which I then converted using ps2pdf. They all display correctly in xpdf  

Now I don't understand the format of these config files yet, maybe someone else knows. There are also tools to generate those config files like ttmkdir and ttfttool but I was unable to compile them for the Z. maybe someone with a linux machine and those tools can generate those config files.

Does that mean generating these config files whenever you add TTF fonts to the Z? Bit of a pain

as for the libgnome libraries, i am now not sure whether they actually need to be recompiled. maybe just fixing the font config files is sufficient. maybe they need recompiling to make the pdf files readable on the Zaurus itself but the generated pdf files seem to be ok if viewed on a PC.

Not so for me, the messed up PDF look the same when viewed both on the Z and on my desktop machine.

-- cheers

[Meanie]

I finally figured out the root of the problem. It is a font config problem.

Thanks for taking the time to diagnose the problem. However I'm not sure I quite follow your explanation  

Anyway to cut to the chase, I've been trying to get PDF output via a roundabout way. Basically I compiled ghostscript and used its ps2pdf to create the pdfs. And the good thing is that there is no need to mess around with Type1 fonts. I only have TTF versions of the fonts that I use, and within each of Abiword, Gnumeric, Inkscape, I "printed" to a ps file which I then converted using ps2pdf. They all display correctly in xpdf  

Now I don't understand the format of these config files yet, maybe someone else knows. There are also tools to generate those config files like ttmkdir and ttfttool but I was unable to compile them for the Z. maybe someone with a linux machine and those tools can generate those config files.

Does that mean generating these config files whenever you add TTF fonts to the Z? Bit of a pain

as for the libgnome libraries, i am now not sure whether they actually need to be recompiled. maybe just fixing the font config files is sufficient. maybe they need recompiling to make the pdf files readable on the Zaurus itself but the generated pdf files seem to be ok if viewed on a PC.

Not so for me, the messed up PDF look the same when viewed both on the Z and on my desktop machine.

-- cheers
[div align=\"right\"][a href=\"index.php?act=findpost&pid=126760\"][{POST_SNAPBACK}][/a][/div]

oh, that might explain it. xpdf and ghostscript both have their own set of type1 fonts. look in their config files and you will notice them pointing to some directory full of .afm and .pfa files. you might have a full set of them and just didnt know
so maybe libgnomeprint does need to be recompiled after all. I had the same setup working as you before, ie print to ps and then use ghostscript to convert to pdf before I recompiled lbgnomeprintui and got everything to work. I also noticed that my current setup only works if I use latin1 fonts, but unicode fonts don't work (missing font config for those fonts)
I'll package up and upload my recompiled libgnomeprintui and libgnomeprint libraries when I get them cleaned up for you to try. what I suggest you try is write a sentence and repeat it using every font in your system and see what the printed result gives. that is how i discovered which fonts worked and which don't and then correlated that the ones that worked had font config entries and the ones that didn't had no entries.

[desertrat]

oh, that might explain it. xpdf and ghostscript both have their own set of type1 fonts. look in their config files and you will notice them pointing to some directory full of .afm and .pfa files. you might have a full set of them and just didnt know

Nope, "find / -name *.afm" and "find / -name *.pfa" doesn't show any. Also in testing whether Type1 fonts were necessary, I specifically installed a non-run-of-the-mill TTF (Alligator Puree to be exact )

so maybe libgnomeprint does need to be recompiled after all. I had the same setup working as you before, ie print to ps and then use ghostscript to convert to pdf before I recompiled lbgnomeprintui and got everything to work. I also noticed that my current setup only works if I use latin1 fonts, but unicode fonts don't work (missing font config for those fonts)
I'll package up and upload my recompiled libgnomeprintui and libgnomeprint libraries when I get them cleaned up for you to try. what I suggest you try is write a sentence and repeat it using every font in your system and see what the printed result gives. that is how i discovered which fonts worked and which don't and then correlated that the ones that worked had font config entries and the ones that didn't had no entries.

Strange. I believe all the fonts on my system are unicode, the MS ones most definitely are (Arial, Verdana, Lucida Console, Courier?, Times?). As you can see from my screenshot they convert to PDF just fine.

Not sure whether this has anything to do with it, but I'm using beta3 which is "UTF enabled".

Also another thing I noticed was that when I used Abiword from beta3 feed, a bunch very old MSWORD files when opened showed empty boxes instead of characters. These same files opened fine when I was using beta1. At the same time, files that I had created with Abiword (from beta1) also opened fine. Now using your version of Abiword, those dodgy MSWORD files can be viewed again.    

pdftest.pdf