Apache OpenOffice (AOO) Bugzilla – Issue 76458
PDF export; font embedding not consistent
Last modified: 2007-11-02 13:12:28 UTC
When exporting to PDF, certain TTF fonts are embedded (with subsetting), others are mapped to (old) Acrobat Reader builtin fonts. I am trying (for interoperability reasons) to use the TrueType versions of URW Nimbus Sans fonts in OOo 2.2 Writer. (URW Nimbus Sans is an Helvetica look-alike.) (included in <http://www.artfiles.org/ghostscript/AFPL/GhostPCL/urwfonts-1.41.tar.gz>.) Installed these 4 TTF fonts via spadmin without problem. I have written an OOo 2 Writer document referencing these Nimbus Sans TrueType fonts. It displays and prints as expected; exporting to PDF is correct; the fonts are embedded in the PDF document. However, when I modify the font family TTF files to have their fontnames defined as Helvetica, Helvetica-Bold, Helvetica-BoldOblique and Helvetica-Oblique (to match Acrobat Reader v4 builtin font names) the following happens: - display and printing work well; the 4 TrueType fonts are suitably embedded (and presumably subset) in the printer PostScript code; - when exporting to PDF, the two Bold fonts are not embedded, instead the PDF documents refers to the corresponding PDF interpreter builtin fonts. In contrast the two non-Bold fonts are embedded (and suitably subset). This is IMO unacceptable for the following reasons: - the behaviour is not consistent between the Bold and non-Bold variants; - now that Adobe ships its PDF Reader (v7) with Myriad and Minion in lieu of Helvetica and Times or TimesNewRoman, it has become a poor choice to avoid embedding for any of the former PDF Base14 fonts (4 Courier variants, 4 Helvetica variants, 4 Times variants, Symbol, Zapf Dingbats). (I believe that not embedding the fonts should be left as an option to the user, with embedding as default behaviour.)
Created attachment 44490 [details] ODT document, TTF font files to test font embedding behaviour
Reassigned to HI.
HI->HDU: Please take over, Thanks.
@pl: as we saw the style names in base14.cxx are wrong for them I can debug more into this and fix it earliest after 2.3.1 though
I accidentially fixed this while solving issue 81970 in CWS pdffix01 (for target 2.3.1). @SBA: Since the testcase here is much better for this exact problem, you might want to use it to verify that the root cause is duplicate since the fix for 81970 solves this one too. *** This issue has been marked as a duplicate of 81970 ***
Though the testcase here is perfect to test this issue which has been fixed indirectly, QA is not interested to verify issues with a "resolved as duplicate" status => closing