Apache OpenOffice (AOO) Bugzilla – Issue 114460
Graphite: Printing page using font LinuxLibertine prints only crap
Last modified: 2017-05-20 10:22:45 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.
Created attachment 71651 [details] PDF export works fine
Created attachment 71652 [details] Source odt-file. Font looks fine on the screen
Created attachment 71654 [details] Scanned print output. Text is defect.
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).
Created attachment 71657 [details] test font (Linux Libertine with Graphite table)
> (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.
confirmed (on unxlngi6 OOO330_m6)
Created attachment 71663 [details] work-around patch as proof of concept
hdu: I believe, it is for the correct PDF text layer. I'm very glad of this new and very important fix. Thanks.
Created attachment 71664 [details] more radical workaround
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.
added to the meta issue
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
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.
@sba: please verify in CWS tl85
@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.
Verified with cws TL85 = ok