Font quandry with Lion

cpragman · 03-10-2012, 11:11 AM

After upgrading to a new iMac with Lion, I find that I am unable to use fonts that I have come to rely on for years. I've got quite a collection of fonts dating back to OS9 and earlier, plus more recent ones. Under 10.5 and earlier, I kept all these non-apple fonts in a specific folder, and used FontBook to activate them.

On my new Lion iMac, I've copied this font folder over, and tried to open the fonts using FontBook. It doesn't seem to want to open any of them though. I can't tell if it is complaining because I'm using a custom folder location to store them, or because they are truly deprecated font formats (ex., suitcase).

If they are deprecated formats, then I'd appreciate any advice that folks might have concerning ways to convert/update them to currently supported formats.

Thanks.

benwiggy · 03-11-2012, 01:47 AM

There should be no problem using old fonts on Lion: it understands Type 1 PostScript, old Mac TrueType, .dfonts, .ttf, .ttc, .otf, and all the rest.

Are you sure the fonts are not corrupted? It's easy to strip the resource fork from old Mac fonts if you put them on a non-HFS formatted disk or send them over a network un-zipped.

benwiggy · 03-11-2012, 04:42 AM

Any font stored in either <user>/Library/Fonts or /Library/Fonts (or sub-folder of either) will be active to the OS and shown in FontBook. (FB can disabled them, of course.) Adding a font to FontBook COPIES (or moves) the font to one of these folders, depending on the preferences and how you add the fonts.

FontBook does not support activating fonts from outside those locations.

If you use Extensis Suitcase or Linotype's FontExplorerX (which I recommend), then you can use other locations to store your fonts and make them available to the system.

cpragman · 03-12-2012, 06:55 AM

Fonts were originally copied isung rsync (which is supposed to preserve resource forks, right?). Tried copying the fonts over again using a disk image (.dmg). This time, they activated with no problems.

benwiggy · 03-12-2012, 07:30 AM

Quote:

Originally Posted by cpragman


	Fonts were originally copied isung rsync (which is supposed to preserve resource forks, right?).

Only if you tell it to. -E is the option.

Hal Itosis · 03-12-2012, 10:57 AM

Quote:

Originally Posted by cpragman

Fonts were originally copied isung rsync (which is supposed to preserve resource forks, right?). Tried copying the fonts over again using a disk image (.dmg). This time, they activated with no problems.

Quote:

Originally Posted by benwiggy

Only if you tell it to. -E is the option.

Unless the user has installed rsync version 3.x, in which case extended attributes are preserved via -X (or --xattrs).

With all the Mac OS updates over the past 2 years, when-oh-when will Apple finally "endorse" version 3.x by installing it? [he asked rhetorically.]

[fwiw, v2.6.9 has a really weird bug (perhaps intermittent?), when copying to afp-mounted volumes.]

ganbustein · 03-15-2012, 10:57 PM

Resource forks and extended attributes are not the same thing.

/usr/bin/xattr confuses the issue, by listing some things that are not extended attributes as if they were. Specifically, it lists the resource fork (if present) as if it were an extended attribute, and lists the FinderInfo block (if different from the default), as if it were another extended attribute. Neither of those pieces of information is stored in the file's extended attribute fork.

rsync wants to know which forks to copy, so to rsync the resources (in the resource fork), the extended attributes (in the extended attributes fork) and the various bits of metadata (FinderInfo, permissions, dates, etc.) stored directly in the catalog are very different classes of information.

It's true that the -E option is an Apple extension that, for convenience, lumps together the resource fork, extended attributes, and ACLs. I don't have version 3.x handy to look at, but I would not expect an attribute synonymous with --xattr to have any effect whatsoever on resource forks. It's probably there so you can say -E --noxattr to copy resource forks (and ACLs), but not extended attributes.

Hal Itosis · 03-16-2012, 09:50 AM

Mike Bombich on HFS+ enhancements in v3.0.7: rsync

Samba.org man page (currently v3.0.9): rsync

[neither mention -E or "resource" forks]

Which reminds me: the other bug with v2.6.9 is that the -E flag always triggers a copy operation... even when absolutely nothing is different.

03-10-2012, 11:11 AM	#1
cpragman All Star Join Date: Jan 2004 Location: Limerick, PA Posts: 687	Font quandry with Lion After upgrading to a new iMac with Lion, I find that I am unable to use fonts that I have come to rely on for years. I've got quite a collection of fonts dating back to OS9 and earlier, plus more recent ones. Under 10.5 and earlier, I kept all these non-apple fonts in a specific folder, and used FontBook to activate them. On my new Lion iMac, I've copied this font folder over, and tried to open the fonts using FontBook. It doesn't seem to want to open any of them though. I can't tell if it is complaining because I'm using a custom folder location to store them, or because they are truly deprecated font formats (ex., suitcase). If they are deprecated formats, then I'd appreciate any advice that folks might have concerning ways to convert/update them to currently supported formats. Thanks.

03-11-2012, 04:42 AM	#3
benwiggy League Commissioner Join Date: Aug 2006 Posts: 5,040	Any font stored in either <user>/Library/Fonts or /Library/Fonts (or sub-folder of either) will be active to the OS and shown in FontBook. (FB can disabled them, of course.) Adding a font to FontBook COPIES (or moves) the font to one of these folders, depending on the preferences and how you add the fonts. FontBook does not support activating fonts from outside those locations. If you use Extensis Suitcase or Linotype's FontExplorerX (which I recommend), then you can use other locations to store your fonts and make them available to the system. Last edited by benwiggy; 03-11-2012 at 04:46 AM.

03-16-2012, 09:50 AM	#8
Hal Itosis Hall of Famer Join Date: Apr 2002 Posts: 3,315	Mike Bombich on HFS+ enhancements in v3.0.7: rsync Samba.org man page (currently v3.0.9): rsync [neither mention -E or "resource" forks] Which reminds me: the other bug with v2.6.9 is that the -E flag always triggers a copy operation... even when absolutely nothing is different. Last edited by Hal Itosis; 03-16-2012 at 10:03 AM.

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode	Rate This Thread:

03-11-2012, 01:47 AM	#2
benwiggy League Commissioner Join Date: Aug 2006 Posts: 5,040	There should be no problem using old fonts on Lion: it understands Type 1 PostScript, old Mac TrueType, .dfonts, .ttf, .ttc, .otf, and all the rest. Are you sure the fonts are not corrupted? It's easy to strip the resource fork from old Mac fonts if you put them on a non-HFS formatted disk or send them over a network un-zipped.

03-12-2012, 06:55 AM	#4
cpragman All Star Join Date: Jan 2004 Location: Limerick, PA Posts: 687	Fonts were originally copied isung rsync (which is supposed to preserve resource forks, right?). Tried copying the fonts over again using a disk image (.dmg). This time, they activated with no problems.

03-15-2012, 10:57 PM	#7
ganbustein MVP Join Date: Apr 2008 Location: Berkeley CA USA Posts: 1,009	Resource forks and extended attributes are not the same thing. /usr/bin/xattr confuses the issue, by listing some things that are not extended attributes as if they were. Specifically, it lists the resource fork (if present) as if it were an extended attribute, and lists the FinderInfo block (if different from the default), as if it were another extended attribute. Neither of those pieces of information is stored in the file's extended attribute fork. rsync wants to know which forks to copy, so to rsync the resources (in the resource fork), the extended attributes (in the extended attributes fork) and the various bits of metadata (FinderInfo, permissions, dates, etc.) stored directly in the catalog are very different classes of information. It's true that the -E option is an Apple extension that, for convenience, lumps together the resource fork, extended attributes, and ACLs. I don't have version 3.x handy to look at, but I would not expect an attribute synonymous with --xattr to have any effect whatsoever on resource forks. It's probably there so you can say -E --noxattr to copy resource forks (and ACLs), but not extended attributes.