It's been so long now since SL's release that I think most folks have forgotten how bad the font engine was in its initial release.
And here i’m just now, in 2015, seriously moving from Tiger to Snow Leopard (Leopard was no-go for me due to an S/MIME crashing bug in Mail introduced by newer WebKit versions with newer Safari versions which Apple never fixed before leaving Leopard behind): hand-me-down Macs, financial situation, etc. I’ve dabbled in Snow Leopard a little bit (and newer OSes less), but not until now am i starting the transition off Tiger.
One known issue never got fixed until Lion, or Mountain Lion. Might have even been Mavericks. I can't recall for certain, though I do know what the bug was.
I’d be curious to know what that bug is, even if it’s pretty obscure or technical. Given that i may need to step through Snow then Lion then jump to one of the newer OSes, i may be dealing with it for awhile.
******
Over the weekend, i did some reading on the Developer site. The correct term for what i earlier referred to as “Gimme a Unicode glyph, bro”, is Font Fallback.
https://developer.apple.com/legacy/library/documentation/Carbon/Reference/ATSUI_ Reference/index.html#//apple_ref/c/tdef/ATSUFontFallbackMethod
Font Fallback Methods
Specify the method by which ATSUI tries to find an appropriate font for a character if the assigned font does not contain the needed glyphs.
Seems like Core Text was rolled out Tiger-Snow, turned on fully in Snow (at least that’s how i interpreted what i read). In terms of Core Text and/or other parts of newer OS X versions’ text handling code:
http://stackoverflow.com/questions/29069362/how-does-apples-text-rendering-draw- a-glyph-that-a-font-doesnt-have
A list of fallback fonts in Core Text is known as a "cascade list", which is an attribute of a CTFontDescriptor (the kCTFontCascadeListAttribute).
The system's default cascade list can be accessed using CTFontCopyDefaultCascadeListForLanguages(). For some reason this function isn't documented on Apple's website yet, but here's its documentation from the 'CTFont.h' header file:[omitted here]
On Mac OS X 10.10, the default English cascade list contains 26 fonts that cover a wide set of languages and symbols.
You can customise the cascade list/fallback fonts for your own CTFont instances by setting the kCTFontCascadeListAttribute attribute of a custom CTFontDescriptor to an array of fallback CTFontDescriptor objects. Then, turn it into a CTFont with CTFontCreateWithFontDescriptor(). If you don't set a custom cascade list on your CTFontDescriptor, it will use the global list by default.
From a WWDC text-related conference in 2012 (my purple text emphasis):
http://asciiwwdc.com/2012/sessions/226
Font fallback, some would say is a crucial component to Unicode text layout because up until recently, it’s been impossible to construct a single font that covers all of Unicode and besides doing so would be prohibitively costly and time-consuming. Basically, Unicode wants you to be able to specify any character in the standard and it’s entirely unlikely that you are going to try to adjust the font for every particular character in that string. It’s very important to be able to rely on having a fallback mechanism in place. Our default mechanism for that we call the system cascade, which is a list of fonts that will consult if the specified font does not cover some or one or more of the characters in the string that you asked to layout. But, in some cases developers have asked for a way to modify the behavior of the system cascade. Well, the mechanism we’ve had in place since the beginning of CoreText, is to use this attribute to specify the cascade list or user cascade list as opposed to the system cascade list. What that is is a list of fonts that you can specify as an attribute to either a font or a font descriptor. We will consult those in order, whenever we need to search for fallback prior to consulting the system cascade.
I did some more testing (Snow Leopard 10.6.8, Safari 5.1.10, Aviator and Firefox versions listed earlier). It seems like fallback or system cascade is simply not working in Snow Leopard with any of these 3 WWW browsers. The test page (http://apps.timwhitlock.info/emoji/tables/unicode#block-1-emoticons) specifies (first in its CSS list) Helvetica Neue, and indeed that’s what’s being used in all three browsers, even when the characters are missing. If i go to a different site (membership site, so i won’t put a link here) which is the actual real-world site where i was seeing the problem (message board where some people are emoji-happy), that site specifies Verdana as its first choice CSS font, and indeed the browsers use Verdana, even when the glyphs are missing.
Now, if i go in with developer tools (i only tried this in Safari and Firefox) and disable the site’s CSS font selection, then the browser drops back to its own default (Times 16 i think in both cases, for sure in Safari), which also is missing those glyphs. The shape of the missing character box changes (actually the stroke thickness more than the shape), but the browser is still using the selected font with no fallback, even with glyphs missing. If i then change that browser’s default to Symbola, then i finally get back to what ATSUI happily gave me with no hassle and no settings changes in Tiger, thanks to fallback working in late ATSUI.
Since font fallback/system cascade appears to not be working in Snow Leopard, i had the “clever” idea of maybe “borrowing” newer versions of Helvetica Neue and Verdana and other popular WWW fonts for my Snow Leopard system. The problem there is that when i checked Character Viewer on my housemate’s MacBook Air running Mavericks, the emoji range was only offered in one font Apple Color Emoji. If the system cascade worked and included (or could be hacked to include) Apple Color Emoji, i might have a fix (for purposes of testing, anyway. Probably not legal for me to “borrow” fonts like that for actual ongoing use).
Bottom line: as Tom has pointed out and Kurt has amplified, it appears that fallback is broken on Snow Leopard, and there’s no easy workaround without overriding automatic site-chosen fonts. There could be involvement from WebKit, though since the problem also occurs on Aviator (ChromeKit) and Firefox (Mozilla), i’m still thinking the problem is in the OS’s text infrastructure.
My parting question: does anyone know when system cascade/font fallback started working again, as in which major OS X version? If it has yet.
Thank you all very much for your time and efforts!
))Sonic((
