Issue 114901 - PDF-export: no special characters when using Type 1 Fonts
Summary: PDF-export: no special characters when using Type 1 Fonts
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 3.3 Beta 1
Hardware: PC Windows 7
: P3 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
: 115697 (view as issue list)
Depends on:
Reported: 2010-10-03 12:09 UTC by iragraves
Modified: 2017-05-20 11:27 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Sample .ODT file to be exported (using Aldus Roman .pfb) (8.81 KB, text/plain)
2010-10-03 12:10 UTC, iragraves
no flags Details
Sample PDF-export (80.33 KB, text/plain)
2010-10-03 12:10 UTC, iragraves
no flags Details
OOo_ExportPDF (26.75 KB, image/jpeg)
2010-10-05 20:38 UTC, eric.savary
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description iragraves 2010-10-03 12:09:02 UTC
This issue is essentially the same as 85979, which has been closed as invalid 
since it was believed to be Ubuntu-specific and solved. The problem arises when 
exporting a document that uses Adobe Type 1 fonts to PDF. In my case I used Aldus 
Roman, which is installed in PFB/PFM format. Instead of the special characters 
which appear perfectly correctly in the .odt, there are just spaces in the .pdf. 
The same goes for all other PFB/PFM fonts I tried. To reproduce, I guess one needs 
the PFB/PFM fonts, since otherwise they are substituted by TTF fonts installed on 
your system which work fine when exporting to PDF.

The problem applies to all prior versions of OO and Windows I know of.
Comment 1 iragraves 2010-10-03 12:10:09 UTC
Created attachment 71926 [details]
Sample .ODT file to be exported (using Aldus Roman .pfb)
Comment 2 iragraves 2010-10-03 12:10:55 UTC
Created attachment 71927 [details]
Sample PDF-export
Comment 3 eric.savary 2010-10-05 05:49:37 UTC
Please send me this commercial font by e-mail mentioning the issue ID in the
subject line.

Also try this again in a current OOo dev 3.3.
Comment 4 michael.ruess 2010-10-05 09:27:41 UTC
MRU->iragraves: could you please check if the problem still happens with OOo 3.3
milestone OOO330m6 or newer? We had a similar problem fixed there (see issue
113851). Thanks a lot!
Comment 5 iragraves 2010-10-05 10:21:06 UTC
I just tried OOO330m9, but ran into a worse problem. Apparently, the font is 
incorrectly embedded in the PDF, at least that is what my Adobe Reader (9.3.4) 
reports: "The embedded font 'Aldus Roman' could not be extracted. Some 
characters may not be shown correctly." (translated from German) And indeed, 
Adobe Reader doesn't show any character in that font, just big dots instead. I 
also tried exporting as PDF-A, with the same result. I therefore can't say 
whether special characters in Type 1 fonts are still an issue in OOO330m9, but 
Type 1 fonts in general definitely still make trouble.

By the way: A workaround is converting the fonts to Opentype/Truetype (e.g. with 
crossfont), everything then works perfectly with both 3.2.1 and 3.3 including 
PDF-export. So it's not about the font itself, but about the Type 1 format.
Comment 6 eric.savary 2010-10-05 20:37:12 UTC
@HDU: as iragraves mentioned, the 3.3 exhibits a much uglier output (see
scrrenshot to be attached).

-> Regression.
Comment 7 eric.savary 2010-10-05 20:38:14 UTC
Created attachment 71962 [details]
Comment 8 2010-10-11 10:59:02 UTC
Adjusting priority to the fact that the type1 era ended long ago. Some important platforms like OSX do not 
even support them anymore. Major font vendors do no longer sell new type1 fonts.

The simplest workaround is to convert the old type1 fonts to the OTF format e.g. using fontforge. The 
conversion does not lose anything but the problems related to parsing pre-unicode AGL names in the 
encrypted parts of the font file available through the GDI API.
Comment 9 Frédéric Buclin 2010-11-02 18:36:24 UTC
I have got the exact same problem as reported by iragraves and es. The generated
PDF is unreadable when using Nimbus New Roman. This was working fine in OOo
3.2.1. This means that all the documents I generate using this font won't work
any longer with the coming version OOo 3.3.

Reaching the RC3 step, I thought it would be stable enough for use for daily
work. An email from a co-worker to tell me the PDF was unreadable just made me
realize OOo 3.3 is super broken. I hope the target milestone of "OOo Later" is
only a mistake, and that this issue will really be fixed before OOo 3.3.0 final!
This is a *severe* regression.
Comment 10 Frédéric Buclin 2010-11-02 19:33:32 UTC
In my previous comment, I meant Nimbus Roman No9 L, not Nimbus New Roman. There
is no good equivalent for this font, Times New Roman being unavailable on Linux.
Comment 11 Mathias_Bauer 2011-02-09 10:52:11 UTC
component changed
Comment 12 johnwhardy 2011-03-17 20:17:32 UTC
I reported bug #115697 which is similar to this bug. I cannot make "Additional Comments" over there without getting the following error message:

"You tried to change the Ever confirmed field from 1 to 0 , but only the assignee of the bug, or a user with the required permissions may change that field."

So I'll try to post a comment here:

Using FontForge to convert Type 1 fonts to a more modern format that OpenOffice can handle was suggested.

I am definitely NOT having fun trying to deal with Cygwin, FontForge, etc. And I am reasonably tech-savvy. I would certainly like to see OpenOffice properly deal with Type 1 fonts. Just because the fonts are old, it does not free OpenOffice from the responsibility of proper support for them, particularly when OO was handling them (almost) perfectly until the recent 3.3 betas and final release. Since something was broken in the beta process, it would be great if it was fixed instead of discarded. Thank you.
Comment 13 Rob Weir 2013-04-02 19:25:59 UTC
*** Issue 115697 has been marked as a duplicate of this issue. ***
Comment 14 Marcus 2017-05-20 11:27:47 UTC
Reset assigne to the default "".