[Libreoffice-bugs] [Bug 51957] New: When using .otf (OpenType PostScript) fonts, em-dashes become en-dashes in exported .pdf files

[bugzilla-daemon at freedesktop.org]

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 at lists.freedesktop.org
        ReportedBy: bugs at 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.