https://bugs.freedesktop.org/show_bug.cgi?id=51957
Bug #: 51957 Summary: When using .otf (OpenType PostScript) fonts, em-dashes become en-dashes in exported .pdf files Classification: Unclassified Product: LibreOffice Version: 3.4.0 release Platform: Other OS/Version: Mac OS X (All) Status: UNCONFIRMED Severity: normal Priority: medium Component: Printing and PDF export AssignedTo: libreoffice-bugs@lists.freedesktop.org ReportedBy: b...@eikota.de At least on MacOS X 10.6.8 (Intel), German UI, all LibreOffice versions I can test: * LibreOffice 3.4.0, OOO340m1 (Build:12) * LibreOffice 3.4.6, OOO340m1 (Build:602) * LibreOffice 3.5.5.3 (Build-ID: 7122e39-92ed229-498d286-15e43b4-d70da21) * LibreOffice 3.6.0.0.beta3 (Build ID: 3e2b862), and also * Apache OpenOffice 3.4.0, AOO340m1 (Build: 9590) - Rev. 1327774 suffer from the following problem. Steps to reproduce: 1) Create a simple Writer (.odt) document 2) Type some text containing some em-dashes ('—', Unicode: U+2014), and, for comparison, some en-dashes ('–', Unicode: U+2013). 3) Set the font of the text to a font in .otf font format (a OpenType font with PostScript curves). Freely available .otf fonts to test with include (I list only some high-quality fonts!): -- Alegreya and Alegreya SC -- Asana Math -- EB Garamond -- Linux Biolinum O -- Linux Libertine O -- Latin Modern Roman -- Latin Modern Sans -- Old Standard 4) Save the document in .odt format (optional?!). 5) Export the document to a .pdf file. 6) Open the .pdf file. You will notice: * that every em-dash has been replaced with an en-dash * that there is a bigger space after every em-dash which 'compensates' for the 'missing length' (in proportional fonts, an em-dash is always longer than an en-dash); * this shows that the metrics (width) has been taken from the real em-dash, but the glyph is just an en-dash. I have done some more testing which makes clear the the language settings of the document and of the individual lines of text don't have any influence on this issue. The same is true for the paragraph alignment (left or justified makes no difference). To show that *all* .otf fonts (OpenType fonts with PostScript curves) are affected, but *only* .oft fonts, I have created a simple sample document which I will attach to this bug report. While it looks fine in all LibreOffice versions, and shows that all fonts I have used in this sample include a valid em-dash glyph, on PDF export all em-dashes of lines that use .otf fonts get converted to en-dashes, while em-dashes in other font formats (.ttf, .ttc, even Apple's .dfont) are exported correctly as em-dashes. The most obvious lines in my sample are the lines using Linux Biolinum and Linux Libertine: the em-dashes which use LibreOffice's internal "Linux Biolinum G" and "Linux Libertine G" (graphite) fonts are exported correctly, but in the lines which use the .otf versions of that fonts, "Linux Biolinum O" and "Linux Libertine O", the em-dashes are converted to en-dashes in the .pdf file. In LibreOffice, however, these lines look absolute identical, as they should. Why is this an important bug? Because .otf fonts are especially used in professional typesetting and by professional users; most commercial type foundrys like Adobe distribute their professional fonts in .otf font format, and it is bad that these expensive fonts are handled so poorly by LibreOffice that even the em-dashes don't work on PDF export. And even if we don't care about professional and expensive fonts, there is an incresing number of high-quality free fonts (see my list above) which is available in .otf font format. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list Libreoffice-bugs@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs