GNOME Bugzilla – Bug 158424
Postscript and PDF backends ignore positions in glyph lists
Last modified: 2005-03-23 19:43:01 UTC
Please describe the problem: The latest development version of AbiWord, 2.1.99 exposed this bug. Justfied text in a user-supplied TTF font looks terrible when printed to ps or PDF. It looks fine in print preview. Steps to reproduce: 1. Install your own TTF(s) in ./fonts (eg Times New Roman) 2. Build AbiWord 2.1.99 or later 3. Type several lines of justfied text in Times New Roman (or another user-suplied TTF). 4. click print-preview (It looks very nice.) 5. Print it, it looks terrible. The justifiaction is all wrong, There are lots of weird and incorrect spaces and gaps between letters and words. Actual results: The generated postscript looks bad every time Expected results: Nicely formatted postscript which looks just like print-preview. Does this happen every time? yes. Other information:
it should be noted that older versions of abiword (2.0.x) also expose this bug with GP 2.8. the bug was not present on my RedHat 8 installation, which had GP 2.2 installed. my wild, off-the-cuff guess is that font subsetting is subtly broken for certain types of TTF fonts. this bug also affected the PDF output, which combined with the alleged 2.8 regression, lends some credibility to my above guess.
Can you give me some sample text ? and the resulting .ps/.pdf files ? I justdid some smoke tests with http://fonts.tom7.com/f/initial.ttf and things came out as expected (in ~/.fonts). I've got the mscore version of Times New Roman installed on my system (under defoma control, not ~/.fonts) and it seemed ok.
Testcase - Get the Microsoft freely distributable Times New Roman font - Change the gedit printing font to "Times New Roman 9" in gconf, key: /apps/gedit-2/preferences/print/fonts/print_font_body and or print_font_body_pango - Open gedit - Load the attached document - Print to PDF. The resulting bad PDF is attached as well.
Created attachment 33853 [details] Gedit test document
Created attachment 33854 [details] Example bad PDF
Additional note: ggv and win32 acrobat display them correctly. {x,g}pdf don't.
Additional note 2: when printing to ps, and converting that to pdf using ps2pdf, all seems to nice.
Created attachment 33859 [details] guadec-4.zabw, gzipped abw file, print this to ps to see the bug
martin : What are you using to view the postscript ?
I used ggv and have printed to our postscript printer at work
I'm not sure this has anything to do with 'user supplied' fonts. I can see problems rendering 'ABC' in times new roman even when that font is included in the system fontconfig (using debian's defoma) The rendering problem is specific to [xg]pdf but the reports of problems from printers is worrying. I'll keep digging.
Jody, DId you make sure that the PS printing problems reported in printers is actually due to libgnomeprint output ? From reading this seems like the issue is happening with a abw file, which don't have to do anything with libgnomeprint. gpdf/xpdf do have many issues with custom encoded fonts etc. so it's not good to judge the print output solely based on display on 'em. If ggv/acroread is also displaying the pdf bad, then we can look into libgnomeprint, otherwise I think the issue is with[x/g]pdf.
suresh : I can replicate the problem using gedit or gnumeric when using microsoft's Times New Roman. The issue of being in ~/.font or system installed is a red-herring. There is a problem rendering the output in [gx]pdf but there are also reports of printers having problems with it too which is why I take it seriously. gv and acroread seem correct. NOTE : the problem I see when rendering ABC is that the C is displayed as an unknown glyph. The original report mentioned problems with alignment and positioning which I can not replicate.
Could you pl. attach your pdf output displaying C as unknown glyph using Times New Roman?
Created attachment 34041 [details] sample pdf generated by cvs head libgnomeprint and gnumeric with microsoft's times new roman font and the text ABC
Here also the output can be displayed fine in ggv/acroread. Also in gpdf in my Solaris. Not in linux [x/g]pdf. Also when I tried to print out from acroread it worked fine. So I won't worry much about this. Users can certainly use ggv if acroread is non-free. Many issue swith gpdf, check http://bugzilla.gnome.org/buglist.cgi?product=gpdf&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
If it was just [gx]pdf I would not worry. Martin's comment #10 suggests that printers are having problems too. I've contact ed the gdpf maintainer to see if they have any insight.
Martin said about the abw output, don't have to do anything with libgnomeprint. See his comment #5, example bad PDF from gedit Later #7 Additional note 2: when printing to ps, and converting that to pdf using ps2pdf, all seems to nice. comment #10 is about the abiword output, mentioned in comment #8. So why worry ?
abiword uses libgnomeprint. Why would we discount examples of bad output ?
We don't have to discount bad output, but need to make sure indeed that's an issue with libgnomeprint :). Otherwise we'll be looking in the wrong place for the bug. If we can get an output from abiword (whatever is attached is some xml format I think, not PDF), it'll be useful, but I cannot see any issue with gedit or the output created by you.
In replay to comment 20. The point is that abiword uses libgnomeprint to do both print-preview and print to ps and pdf. The output to print preview is perfect. The output to ps and pdf sucks rocks. Believe me we very carefully examined whether or not this was abiword's fault and decided it wasn't. I'll attached the ps and pdf output from the sample abiword document. The attached document is a native abiword document. Load it with abiword-2.2 to see the perfect print-preview and the bad ps and pdf.
Thanks. pl. attach 'em and we'll see.
Created attachment 34049 [details] here is the OUTPUT from the guadec-4.zabw document. It is a gzipped postscript file. This file a gzipped postscript file.
Created attachment 34052 [details] This is a gzipped pdf of the guadec-4.abw document This is the gzipped pdf output from guadec-4.zabw. The text in this is meant to be fully justified. ie Stretch evenly across the page. It looks good in abiword and in print preview in abiword.
I cannot print out both the docs here. Only a page of the PDF, which looks OK. Printer gives me a blank look with the PS output, and I have a highend network printer. A few questions. 1. If you're using some tother font then the printing is OK, only happening with the Times New Roman ? 2. Could you be able to print a minimal text page with the issue, like a couple of lines, or better a single line with the problem. This will help a lot to scope out. Pl. avoid the images. Like the sample 3 letter test case Jody produced ?
Created attachment 34053 [details] gzipped Postscript file with font Nimbus Roman number 9 gzipped binary file with numbus roman number 9 font. Just the first page of the same document. Looks beautiful.
Created attachment 34054 [details] gzipped postscript file with font Times New Roman gzipped first page with font Times New roman. Look at the ensuing ugliness.
It appears to happen with any TTF font. Even the bitstream vera set. Type 1 fonts like Nimbus Roman Number 9 work fine. You really need a full page to see how the spacing is totally screwed. In all cases these look perfect in print-preview.
This is interesting, will look into this after thanksgiving. BTW, was this working with the earlier versions of libgnomeprint, I mean before libgnomeprint 2.7.0 ?
suresh : Dom's comment #1 seems to indicate that things worked pre-2.7.0
oops, missed that comment, Can somebody pl. attach a pdf from pre 2.7 GP + abiword for the same document ?
I looked into these and since we don't have supply of A4 paper here I changed the documents to be in US format for printing. (by changing the PageSize to /PageSize [612 792] ) Both #34053 and #34054 printed fine for me, at least in the way it looked in the print preview, except that th header got cut off a bit (which will go away if I adjust the positioning which was created for A4). So it looks like it's issue for some specific printers. So I request you to cvs co compile and install LIBGNOMEPRINT_2_6_2 branch of libgnomeprint and attach the output (which's the version before ttf font subsetting) which's working. Seems like this issue may be with some specific printers. But certainly needs to be resolved if it's a regression.
Created attachment 35146 [details] LIBGNOMEPRINT_2_6_0 library LIBGNOMEPRINT_2_6_0 library
Hi, Could you check this issue is happenign with the attached version of the libgnomeprint library ? Just copy this file to /usr/lib and test, have created this in a 9.1 SUSE machine. This is just libgnomeprint_2_6_0 (without the font subsetting)
Created attachment 35147 [details] libgnomepritn 2.6.0 plus tt initial subsetting code
here id=35146 is for comment #34 id=35147 is 2.6.0 code plus initial font subsetting code, so pl. test with these both and see whether they work. pl. attach the output files from both these (both PS and PDF)
It will take me a few days to do these tests. If you want to generate your own postscript with AbiWord you get the latest binaries from http://ftp.gwdg.de/pub/linux/usr-local-bin/9.1/ and download abiword-2.2.2 The binary is called AbiWord-2.2
Martin : any news ?
Sorry No. I'll try to run some tests within a couple of days.
martin : ping? I'd really like to see this resolved. How do things look with 2.10.0 ? please grab me on irc I want to get this resolved and there are some potential patches to CVS that may impact this.
The bug is still present. See the attached document viewed with either ggv or xpdf. I used libgnomeprint from CVS HEAD.
Created attachment 38934 [details] smaller sample The 1.0 in the first line is odd.
re-titling. By using straight '(foo) show' we are assuming that the glphs are positioned exactly at their widths. Applications like abi that do justification of their own are completely ignored.
Ok, CVS (which will become 2.10.2) has patches for ps2 and pdf.
Looks fixed to me using abiword to drive the gnomeprint.
*** Bug 164230 has been marked as a duplicate of this bug. ***