Issue 114460

Summary: Graphite: Printing page using font LinuxLibertine prints only crap
Product: gsl Reporter: gleppert <gleppert>
Component: codeAssignee: stefan.baltzer
Status: CLOSED FIXED QA Contact: issues@gsl <issues>
Severity: Trivial    
Priority: P3 CC: devel, hdu, issues, nemeth.lacko
Version: OOo 3.3 Beta 1   
Target Milestone: OOo 3.3   
Hardware: All   
OS: Unix, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 111112    
Attachments:
Description Flags
PDF export works fine
none
Source odt-file. Font looks fine on the screen
none
Scanned print output. Text is defect.
none
test font (Linux Libertine with Graphite table)
none
work-around patch as proof of concept
none
more radical workaround none

Description gleppert 2010-09-12 19:57:53 UTC
I tried my first steps with Graphite Support in OpenOffice.org. 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: http://www.numbertext.org/linux/

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 Openoffice.org (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 ThanLWinSoft.org).
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 ThanLWinSoft.org).
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 hdu@apache.org 2010-09-13 12:01:31 UTC
confirmed (on unxlngi6 OOO330_m6)
Comment 8 hdu@apache.org 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 hdu@apache.org 2010-09-13 13:32:40 UTC
Created attachment 71664 [details]
more radical workaround
Comment 11 hdu@apache.org 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 hdu@apache.org 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 
OOo3.x
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 hdu@apache.org 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
purposes.
Comment 17 h.ilter 2010-09-20 15:03:44 UTC
Verified with cws TL85 = ok