Issue 114460 - Graphite: Printing page using font LinuxLibertine prints only crap
Summary: Graphite: Printing page using font LinuxLibertine prints only crap
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 3.3 Beta 1
Hardware: All Unix, all
: P3 Trivial (vote)
Target Milestone: OOo 3.3
Assignee: stefan.baltzer
QA Contact: issues@gsl
Depends on:
Blocks: 111112
  Show dependency tree
Reported: 2010-09-12 19:57 UTC by gleppert
Modified: 2017-05-20 10:22 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

PDF export works fine (88.29 KB, text/plain)
2010-09-12 19:58 UTC, gleppert
no flags Details
Source odt-file. Font looks fine on the screen (15.37 KB, application/vnd.oasis.opendocument.text)
2010-09-12 19:59 UTC, gleppert
no flags Details
Scanned print output. Text is defect. (2.13 MB, image/jpeg)
2010-09-12 20:04 UTC, gleppert
no flags Details
test font (Linux Libertine with Graphite table) (457.36 KB, application/x-compressed)
2010-09-13 07:33 UTC, nemeth.lacko
no flags Details
work-around patch as proof of concept (1.52 KB, patch)
2010-09-13 13:09 UTC,
no flags Details | Diff
more radical workaround (2.21 KB, patch)
2010-09-13 13:32 UTC,
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description gleppert 2010-09-12 19:57:53 UTC
I tried my first steps with Graphite Support in However, it
ended quite soon, because I was not able to properly print text written in the
font MagyarLinuxLibertine. It prints out just crap. MagyarLinuxBiolinum,
however, worked fine.
I used the fonts from:

Please see attached files: 
The top left cell in the table is using Font Linux Libertine.
Please compare the Untitled1.pdf with SCAN-Untitled1.jpg

You see that there is something wrong with the printout.

System: Ubuntu 10.04, OOO-dev 3.3Beta1 from (issue also happens
with 3.2.1 that comes with Ubuntu), Oki Laser Printer 430dn.
Comment 1 gleppert 2010-09-12 19:58:52 UTC
Created attachment 71651 [details]
PDF export works fine
Comment 2 gleppert 2010-09-12 19:59:39 UTC
Created attachment 71652 [details]
Source odt-file. Font looks fine on the screen
Comment 3 gleppert 2010-09-12 20:04:07 UTC
Created attachment 71654 [details]
Scanned print output. Text is defect.
Comment 4 nemeth.lacko 2010-09-13 07:30:36 UTC
Next release of the Graphite version of (Magyar) Linux Libertine will use the 
original TrueType fonts, maybe solving the printing problem. I attach a 
preliminary version from the Regular variant for testing purpose. It contains 
default ligatures (but all ligatures defined in the OpenType Linux Libertine, eg. 
Th, tt), also converted OpenType substitution and ligature tables (use Graphite 
Font Extension from
Comment 5 nemeth.lacko 2010-09-13 07:33:59 UTC
Created attachment 71657 [details]
test font (Linux Libertine with Graphite table)
Comment 6 nemeth.lacko 2010-09-13 07:38:13 UTC
> (use Graphite Font Extension from
to see all features. The Graphite features are labelled by OpenType names now, 
eg. to switch on K, J, R variants, use Linux Libertine:ss02=1 extended font name.
Comment 7 2010-09-13 12:01:31 UTC
confirmed (on unxlngi6 OOO330_m6)
Comment 8 2010-09-13 13:09:43 UTC
Created attachment 71663 [details]
work-around patch as proof of concept
Comment 9 nemeth.lacko 2010-09-13 13:30:13 UTC
hdu: I believe, it is for the correct PDF text layer. I'm very glad of this new
and very important fix. Thanks.
Comment 10 2010-09-13 13:32:40 UTC
Created attachment 71664 [details]
more radical workaround
Comment 11 2010-09-13 13:35:26 UTC
I analyzed the problem and developed the both proof-of-concept workaround above. The reasons that 
the first patch works seems to be that
- GraphiteServerLayout returns a char_index that is off by mnMinCharPos (relative to text_ptr)?
- PrinterGfx uses these unicode codepoints somehow for caching?
- and gets confused by different unicode->glyph mappings?

This raises some important questions though. With CTL text having non-1:1 unicode->glyph 
mappings and non-trivial glyphidx->stringidx mappings being quite common if there is a dependency 
in PrinterGfx on other assumptions then we have a problem.
Why are the unicode codepoints used anyway when perfectly fine glyph indices are available? The 
second workaround is more more radical and patches out the reverse mapping into the string 
altogether. It seems to work too...

Other than that the GraphiteServerLayout should behave similarly to the other Layouts regarding the 
returned char positions.
Comment 12 Olaf Felka 2010-09-13 14:48:27 UTC
added to the meta issue
Comment 13 2010-09-13 15:19:11 UTC
To reduces the risk I applied a minimal-invasive version of my second patch to OOo330 CWS tl85. The 
change works around the problems mentioned in #desc12, but they still need to be addressed e.g. for 
Comment 14 gleppert 2010-09-13 16:52:54 UTC
Wow, you are great people! Thank you very much for your work.
Before a new beta will be released with the patch, I will try out the test font
which Laszlo has attached today.
Comment 15 2010-09-15 08:52:23 UTC
@sba: please verify in CWS tl85
Comment 16 philipp.lohmann 2010-09-20 10:43:15 UTC
@hdu: unicode points are used since some people want ascii text to appear in the
PostScript as ascii code points, not arbitrary glyph ids for postprocessing
Comment 17 h.ilter 2010-09-20 15:03:44 UTC
Verified with cws TL85 = ok