Issue 114901

Created attachment 71926 [details]
Sample .ODT file to be exported (using Aldus Roman .pfb)

Created attachment 71927 [details]
Sample PDF-export

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.

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!

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.

@HDU: as iragraves mentioned, the 3.3 exhibits a much uglier output (see
scrrenshot to be attached).

-> Regression.

Created attachment 71962 [details]
OOo_ExportPDF

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.

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.

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.

component changed

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.

*** Issue 115697 has been marked as a duplicate of this issue. ***

Reset assigne to the default "issues@openoffice.apache.org".