GNOME Bugzilla – Bug 161579
pango_create_layout scrambles fonts
Last modified: 2005-03-12 21:28:07 UTC
I compiled gnumeric 1.4.1 on Apple OS X 1.3 with pango-1.7. The print preview and printing worked, but the fonts were scrambled. Basic characters were replaced with extended-latin accented characters. For example the letter A (0x0041) was replaced by an accented R (0x0154) and the numeral 1 (0x0031) was replaced by an accented I (0x00cc). This happened both in the preview and on the printer, but not in the spreadsheet display. I commented out these two lines in gnumeric-config.h: /* #define HAVE_GNOME_PRINT_PANGO_CREATE_LAYOUT 1 */ /* #define HAVE_PANGO_LAYOUT_SET_ELLIPSIZE 1 */ and recompiled. Then everything was fine.
This feels like a libgnomeprint bug. What version are you using? Also, please provide a sample sheet. (Your workaround has lots of other problems. The code for that will disappear when we branch.)
I am using libgnomeprint-2.8.2 and libgnomeprintui-2.8.2. What would you like in the way of a sample sheet? How about a pdf file?
Sample sheet and the pdf/ps it produces would be great. Notice, btw., that you can switch between new and old printing code simply by setting USE_OLD_PRINT in the environment -- no recompilation needed.
Created attachment 35057 [details] sample sheet
Created attachment 35058 [details] output of sample sheet with new printing code
Created attachment 35059 [details] output of sample sheet with old printing code
Ok, confirming that the pdf file looks screwed on my machine too.
1. Is this font dependent? 2. Does it work for print preview?
The generated pdf file (comment 5) generates sequential codes for characters in the pdf file. This does not happen for me, possibly because I don't have the "Luxi Sans" font. In the pdf file I notice... /Type /Encoding /BaseEncoding /MacRomanEncoding /Differences [1 /Imacron /edotaccent /aring /gbreve /Uhungarumlaut /ecaron /lacute /Scaron /ccedilla /cacute /iacute /idieresis /Racute /agrave /Idieresis /Rcaron /acircumflex /Iacute /Sacute /abreve /Igrave /atilde /Icircumflex /Scedilla /Idotaccent /Tcaron /aogonek /Lacute /Udieresis /Lcaron /Uacute /ccaron /Nacute /Ugrave /Ncaron /Ucircumflex /dcaron /Gbreve /Uring /edieresis /eacute /Yacute /egrave /Zacute /ecircumflex /Zcaron /Zdotaccent /Amacron /eogonek /Tcommaaccent /Ydieresis /Emacron /igrave /Iogonek /icircumflex /Kcommaaccent /Lcommaaccent /lcaron /Ncommaaccent /nacute /Omacron /ncaron ] which, quite frankly, looks wrong. It also happens to be the characters displayed. -->libgnomeprint.
It looks the same in preview as it does when it prints. Yes, it is font dependent! I should have noticed that before. In fact, the only fonts that cause trouble are Luxi Mono, Luxi Sans and Luxi Serif. Also, these are the only fonts that come with the Apple X server which are listed as available in the adobe-standard encoding. (None of my ghostscript fonts are listed with that encoding.) These fonts are supplied in both TTF and Type1 formats (/usr/X11R6/lib/X11/fonts/TTF and /usr/X11R6/lib/X11/fonts/Type1). Here is a snippet from the Type1 fonts.dir file: Type1/fonts.dir:l048013t.pfa -b&h-Luxi Sans-medium-r-normal--0-0-0-0-p-0-iso8859-1 Type1/fonts.dir:l048013t.pfa -b&h-Luxi Sans-medium-r-normal--0-0-0-0-p-0-iso8859-2 Type1/fonts.dir:l048013t.pfa -b&h-Luxi Sans-medium-r-normal--0-0-0-0-p-0-iso8859-9 Type1/fonts.dir:l048013t.pfa -b&h-Luxi Sans-medium-r-normal--0-0-0-0-p-0-iso8859-15 Type1/fonts.dir:l048013t.pfa -b&h-Luxi Sans-medium-r-normal--0-0-0-0-p-0-adobe-standard I don't know how these encodings differ. Could it be that the pfa file is really is encoded in adobe- standard but the new printing code assumes it iso8859 ??? The pfa files for the Luxi fonts contain custom encoding arrays, while the others just have: /Encoding StandardEncoding def
I read up on the Luxi fonts. It turns out that they are 16 bit fonts. So I guess the bottom line is that the new print code doesn't handle 16 bit fonts correctly.
*** This bug has been marked as a duplicate of 159573 ***