I am having a font problem where some of my system wide fonts work fine in carbon based apps (MS Word, Adobe Illustrator, AppleWorks, etc), but not in cocoa based apps (Pages, Omni Outliner, etc). The affected fonts appear fine in FontBook. In the affected cocoa apps, the affected fonts are listed in the font selection tool, but I get a generic font san serif font instead of the selected font in the preview. The font does not get applied to the document.
I have tried:
Reboots, Safe Startups, Font Doctor, deleting font related preferences.
I am still trying to solve a mysterious problem with fonts working fine in Carbon, but not in Cocoa apps. It appears that there is something remapping fonts when in Cocoa applications for example ZapfDingbats is changed to "LucidaGrande".
To recap all of my actions:
DiskDoctor and DiskWarrior
Tiger Cache Cleaner and Onyx to delete caches.
Deleted font related preferences. (Am I missing something?)
Removed all fonts except /System/Library/Fonts
Copy clean copies of these core fonts from the Tiger DVD
Restarted and Login in Safe Boot mode
Run Font Doctor
Log in with other user accounts
After doing all of this and with the minimal font set, I have observed the following:
Carbon apps still work fine
Cocoa apps do not handle two of the core system fonts:
Symbol.dfont
ZapfDingbats.dfont
iWork's Pages reports ZapfDingbats is MISSING if I open a document that
uses that font.
When in a a Cocoa app the font selection Palette (the one that you ususally open with command-t) behaves funny.
Open TextEdit, enter some text, select that textm, open the font Palette. The working fonts behave as expected. Select the font in the font tool, you see a preview of the font using the font name as and sample text, and in the editor the selected text is changed to that font.
But for Symbol and ZapfDingbats strange things happen. Lets try to apply the Symbol font to the selected text in TextEdit:
First Click on font in Pallet:
Palette preview is BLANK
selected text in editor UNCHANGED
Second Click on font in Palette:
Palette preview says "Symbol" in the "Times" font.
selected text in editor CHANGED to "Times" font.
Additional Clicks on font in Pallet:
Palette preview says
_"Times"_ in the "Times" font.
selected text in editor CHANGED to "Times" font.
If I did the above steps using ZapfDingbats a similar thing happens but with "LucidaGrande" replacing "Times".
Now to make things stranger yet:
Go the the "International Menu" and select the "Character Palette". I can view characters in the Symbol and Dingbats fonts and insert them into the TextEdit document where they are displayed correctly. If I select the inserted character the font palette correctly identifies the font. However, if I select the font and start typing instead of getting the expect result of the new characters keeping the Symbol or Dingbat font, they get changed to Times or LucidaGrande respectively.
I am beginning to fear that I will have to reinstall Mac OS X.....
I see the same wierd behaviour in textedit as you documented above. It also happens on all my machines. It seems like a font problem - not an OSX problem.
Before reinstalling the whole OS, I would see if there is another version of dingbats or other fonts that you might use. I found that "ITC Zapf Dingbats" does not have this problem and works correctly. If you have Adobe apps installed, you might find this version in /Library/Application Support/Adobe/Fonts/Reqrd/Base. You can move the font files to one of the OS X font directories and all applications will see it.
However, if I select the font and start typing instead of getting the expect result of the new characters keeping the Symbol or Dingbat font, they get changed to Times or LucidaGrande respectively.
OS X/Cocoa apps are designed to use Unicode fonts. Using non-Unicode fonts for symbol and dingbats, which substitute symbols for Latin and are quite common (and necessary in non-Unicode apps like AppleWorks, WordX, etc) may work in some Cocoa apps in some circumstance, but it is unreliable and should be avoided if possible.
All of this is really caused by the fact that Unicode is supported, but not fully by all, apps in OS X.
Basically, Zapf Dingbats used to be just a font that substituted symbols for letters. In a letter font, you press A, you get A. Use Dingbats, you press A, you get a snowflake.
Under Unicode, the first "plane", or set, of characters defines specific code numbers for every character in a zillion languages, as well as special things like dingbats and other symbols. The letter A has one numeric ID (let's say it's 65); the snowflake that you used to get w/the A key has an entirely different numeric ID (let's say 450).
A Unicode font (or, more correctly, a Unicode-compliant font) has its characters in the assigned slots: if there's in A, it's in slot 65; if there's a snowflake, it's in slot 220.
Now, with that in mind: Select Zapf Dingbats and type the letter A. Nothing happens because there is no letter A in Zapf Dingbats--that font has nothing in slot 65. But, OS X to the rescue! When you try to enter a character that doesn't exist in the current font, it runs around looking for a font that
does have that character - and it always looks to Lucida Grande first. It finds an A, and it give you an A, necessarily changing the font as well. Of course, this all happens so fast that you don't realize there was a problem with the A and Zapf Dingbats - all you see is the font change and an A you didn't expect.
The confusion is compounded because some apps are smart enough to realize that if you selected Zapf Dingbats, you want Zapf Dingbats, and they give you the items you are typing. (Try copying a string of dingbats from Word and pasting them into Text Edit.) But take a look at the Keyboard Viewer: select Zapf Dingbats and it displays the alphabet from Lucida Grande.
Earlier OS X provided a special Z.Ding. keyboard, just as if it were a foreign language - don't know why it's not in Tiger.
We're in the midst of a big change in terms of how fonts are coded behind the scenes; it should all clear up in a couple of years <g>.
Earlier OS X provided a special Z.Ding. keyboard, just as if it were a foreign language - don't know why it's not in Tiger.
The special keyboards for Symbol and Z. Dingbats were discontinued with 10.2/Jaguar when the Character Palette was added, which is a more logical way to access the full range of such characters in a Unicode system. Although it would not be much trouble to make a custom keyboard with those dingbats you wanted using the tool at
The special keyboards for Symbol and Z. Dingbats were discontinued with 10.2/Jaguar when the Character Palette was added, which is a more logical way to access the full range of such characters in a Unicode system.
I know that... when I said "I don't know why it's not in Tiger [ZDing kbd]" I meant: I don't know why the heck they didn't keep a Zapf keyboard available when it's easier and more intuitive and less screen-hogging than the Character Palette <g>.
For my own use, Z.Dingbats was, more than anything, used for those circled numbers, which are available in so many of the system/Microsoft/Adobe supplied fonts, and they go way past 10, so I don't actually use ZD anymore. But if even the Unicode Consortium acknoweledged the worldwide use and importance of dingbats by giving them their own clump of code points, wouldn't you think that the Mac, of all machines, would make them more easily accessible? And that Mac programs could standardize on how they're handled.. oh wait, that would require cooperation from Microsoft... and Adobe... and.... <sigh>
Oh, and thx for the info re Ukelele; I just skimmed the webpage and it looks very interesting. While I don't need it, you can never have too many toys... I mean tools...
