Bug 37453 - Classic Mac PostScript Type 1 fonts are not recognized at all
Summary: Classic Mac PostScript Type 1 fonts are not recognized at all
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86 (IA32) Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: MacOS-Wishlist
  Show dependency treegraph
 
Reported: 2011-05-22 01:53 UTC by Rabendoktor
Modified: 2017-07-26 15:13 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rabendoktor 2011-05-22 01:53:24 UTC
Hi there,

contrary to OO, LO does not recognize the installed (bought!) postscript-fonts (type 1, p.e. Frutiger) on my iMac... OO 3.3 does this without any prob...
Comment 1 Björn Michaelsen 2011-12-23 12:02:09 UTC Comment hidden (obsolete)
Comment 2 Roman Eisele 2012-05-09 01:33:37 UTC
Hint:
I will look into this issue, so nobody else needs to do so. I will report the results as soon as I come to some conclusion ...
Comment 3 Roman Eisele 2012-05-09 10:41:05 UTC
REPRODUCIBLE with LibreOffice 3.5.3.2 (Build-ID: 235ab8a-3802056-4a8fed3-2d66ea8-e241b80), German langpack installed, on MacOS X 10.6.8 German.

REPRODUCIBLE with LibreOffice 3.4.6, German langpack installed, on MacOS X 10.6.8 German.

REPRODUCIBLE with LOdev 3.6.0alpha0+ (Build ID: c92c5c6) (installation file: master~2012-05-03_05.23.04_LibO-Dev_3.6.0alpha0_MacOS_x86_install_en-US.dmg)


Description/Background:

Classic Mac PostScript Type 1 fonts, consisting of the old combination of
* LWFN files, one for each font face (Regular, Italic, Bold ...), containing the actual PS1 fonts in the resource fork
* FFIL files or 'suitcases', at least one per font family, containing the bitmaps and some font family information in the resource fork,
work still fine with MacOS X 10.6.8 German: if installed, they show up in Apple's FontBook utility, and can be used with Apple's TextEdit Application, QuarkXPress, and many (most or all?) applications.

But not with LibreOffice. They just don't appear in the font menu, so you can't even try them. To reproduce, just install some classic Mac PostScript Type 1 fonts, start LibreOffice, create a new Writer document and check the font menu. No one of the fonts appears.

I remember this problem since I use LibreOffice. If I remember correctly, it was already present in 3.3.x (but I don't have an installed version of 3.3.x anymore, so I can't test. It is at least present since 4.0.


About the Importance of this Issue:

This problem looks minor, because most people use TrueType fonts (normal users, office users) or OpenType fonts (DTP and other professionals) now. But please don't underestimate the importance of this problem. Especially Mac users have often bought many expensive fonts from professional font developers like Adobe, Monotype, Berthold, URW, Linotype, Agfa, etc., and in the 1990s and even early 2000s, most of these fonts used the classic Mac PostScript Type 1 fonts format. I have already converted some old freeware PS1 fonts to OpenType PS format in order to make them usable for me with LibreOffice. But this conversion needs a good font editor like FontLab (expensive) or fontforge (hard to get for Mac), experience and time; it may be illegal or at least of disputed legality with commerical fonts; and is therefore not suitable for most users.

So it would be wonderful if this long-standing issue could get resolved ...
Comment 4 Roman Eisele 2012-05-09 10:48:27 UTC
(Made summary a bit more precise.)

@Thorsten Behrens:
According to https://wiki.documentfoundation.org/FindTheExpert, you are our "Friendly expert" for MacOS issues ;-), therefore I have added you to the CC of this Mac-only bug report.

It is one of many many bugs, I know, but maybe you can find the time to take a look at it. The issue may be more important than it looks at the first glance (I know quite some people still using these old fonts, which were very expensive in the 1990s and 2000s).

And the issue is even more important if OOo really recognizes these fonts, but we don't do so :-(. If it is really a regression (can't test), it may even be rather easy to fix?!

Thank you very much!
Comment 5 Roman Eisele 2012-05-09 12:29:21 UTC
A kind of “all clear” ('Entwarnung'): I just tested the new Apache OO 3.4 build for MacOS X, and it does not show the classic Mac PostScript Type 1 fonts either. If this is a regression, LibO and AOO share it ...
Comment 6 Rabendoktor 2012-05-09 23:40:17 UTC
in OOO 3.3, these fonts positively were recognized and supported...
Thanks for Your efforts to solve this quest!
Comment 7 Dave Brown 2013-10-06 09:45:28 UTC
This issue is still apparent in the latest release candidate (4.1.2.3) under Ubuntu 13.04.

It is a bug of some importance, as it is a regression of functionality vs. Windows Office.

Folks have used these fonts in earlier documents, and want to be able to continue to use them (the fonts).  It is quite an annoyance when one opens

It appears that OO (I tested this with 4.0.1) does *not* handle this correctly either.
-d
Comment 8 dshelton 2013-12-22 05:28:39 UTC
I confirm this bug also occurs under Xubuntu 12.04 and Bodhi Linux 2.4.0 with LO 4.1.3.2.  I have added both TrueType and Type 1 fonts to my system; other applications including leafpad and Abiword can successfully use both.  LibreOffice sees only the TrueType fonts I've added.

Note, this problem is *not* present in LibreOffice under Windows 7.  I have added Type 1 fonts to Win7 and used them successfully under LO 4.1.1.2.  They also work in MSOffice programs.

Please let me know if there is anything I can do to help squash this bug.
Comment 9 dshelton 2013-12-22 05:41:12 UTC
Also, this applies to Type 1 fonts from any source, not just classic Mac. Several purchased fonts have this issue.
Comment 10 Khaled Hosny 2013-12-22 20:00:12 UTC
I don’t know about Mac, but on Linux you need AFM files as well as the Type 1 fonts, or our font manager will reject them as unusable (some info that is only available in AFM files are needed).
Comment 11 dshelton 2013-12-23 17:33:37 UTC
I see the bug has been altered to only reference Mac OSX and IA32 hardware.  Should I open another bug for the same problem under Linux 32 and 64-bit?  Seems odd to duplicate bugs but I'll be happy to do so.
Comment 12 dshelton 2013-12-23 18:08:47 UTC
Thank you, Khaled Hosny!  I have verified the problem I see is due to a lack of .afm files.  It doesn't explain why other apps seem to be able to work with only the .pfm files, though.  I will update several forum posts with this info, as I am aware of many posts asking the same question.  Is it acceptable to open a bug for an enhancement request to support operation without .afm?
Comment 13 Khaled Hosny 2013-12-23 19:07:20 UTC
(In reply to comment #12)
> Thank you, Khaled Hosny!  I have verified the problem I see is due to a lack
> of .afm files.  It doesn't explain why other apps seem to be able to work
> with only the .pfm files, though.  I will update several forum posts with
> this info, as I am aware of many posts asking the same question.  Is it
> acceptable to open a bug for an enhancement request to support operation
> without .afm?

I’d personally drop Type1 support altogther, but sure open an issue for may be someone else would be interested in adding .pfm support.
Comment 14 Caolán McNamara 2014-03-14 14:46:06 UTC
This issue needs a link to, or an attachment of, a sample (legally redistributable) font of the afflicted type seeing as there aren't any in a fresh MacOSX install
Comment 15 Joel Madero 2015-05-02 15:41:29 UTC Comment hidden (obsolete)
Comment 16 Buovjaga 2015-11-13 16:51:06 UTC
*** Bug 95737 has been marked as a duplicate of this bug. ***
Comment 17 Khaled Hosny 2016-11-12 00:17:31 UTC
We are (officially) dropping support for Type 1 and other non-SFNT font formats in 5.3.
Comment 18 V Stuart Foote 2016-11-12 00:24:14 UTC
@Khaled, with ESC decision--this becomes a WONTFIX rather than invalid.