Comments on: Greek Support in Fonts: Truth & Lies http://www.thomasphinney.com/2009/02/greek/ the Phinney-us Blog on Typography & Text Mon, 19 Jul 2010 11:32:07 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Adam Twardoch http://www.thomasphinney.com/2009/02/greek/comment-page-1/#comment-39 Adam Twardoch Fri, 06 Feb 2009 11:02:33 +0000 http://www.thomasphinney.com/?p=134#comment-39 There is this other side to that as well: Mac OS X and Adobe applications had a mechanism of sorting the font menu in applications that sometimes backfired. The character set of old Type 1 fonts typically had one codepage, so a Type 1 font was usually "Western" or "Central European" or "Cyrillic" or "Greek". So Apple and Adobe had an idea to make it easier for users to locate all of the fonts that support their primary character set: the font list in the font menu was sliced into blocks by the primary codepages. First, all the Western fonts were listed, then the Central European fonts, then Cyrillic etc. For OpenType fonts, this method worked well in some cases but was counter-intuitive in other cases. For example, OpenType "Pro" fonts that only contained the Western+CE character set landed in the Central European section of the menu (all the way down the list) so most Western clients thought they were missing from the menu altogether and complained. The menu sorting logic worked the way that if the font only claims the coverage of the Western codepage and one non-Western codepage, the font would be sorted among its non-Western "colleagues" but if the font reports the Western codepage and two or more non-Western codepage, then it would be placed among the Western fonts in the menu. So if someone designed a Latin+Cyrillic font or a Western+Central European, but wanted the font appear in the Western part of the list (so Western users would not be confused by its absence in the "usual" section of the font menu), a short-term fix was to set the Greek codepage bit in the font (in addition to the ones that were already legitimately set) even if that font did not really have any Greek characters, so Mac OS X and Adobe apps would start counting the font as a "three-or-more-codepage font" and therefore place it in the Western section of the menu. Incidentally, because the early Adobe fonts DID set the Greek bit "overenthusiastically" as Thomas just described, this misbehavior of the Adobe and Apple applications largely went unnoticed in the initial phase. I also believe that the more recent versions of Adobe apps and Mac OS X are behaving more rationally, so the fonts are listed in the Western menu section more easily, without forcing the font vendor to resort to tricks such as setting fake Greek bits. <i>[Yes, this was fixed quite a few years ago, so I don't think there is any remaining reason to set the bits incorrectly. - T]</i> There is this other side to that as well: Mac OS X and Adobe applications had a mechanism of sorting the font menu in applications that sometimes backfired. The character set of old Type 1 fonts typically had one codepage, so a Type 1 font was usually “Western” or “Central European” or “Cyrillic” or “Greek”. So Apple and Adobe had an idea to make it easier for users to locate all of the fonts that support their primary character set: the font list in the font menu was sliced into blocks by the primary codepages. First, all the Western fonts were listed, then the Central European fonts, then Cyrillic etc.

For OpenType fonts, this method worked well in some cases but was counter-intuitive in other cases. For example, OpenType “Pro” fonts that only contained the Western+CE character set landed in the Central European section of the menu (all the way down the list) so most Western clients thought they were missing from the menu altogether and complained.

The menu sorting logic worked the way that if the font only claims the coverage of the Western codepage and one non-Western codepage, the font would be sorted among its non-Western “colleagues” but if the font reports the Western codepage and two or more non-Western codepage, then it would be placed among the Western fonts in the menu. So if someone designed a Latin+Cyrillic font or a Western+Central European, but wanted the font appear in the Western part of the list (so Western users would not be confused by its absence in the “usual” section of the font menu), a short-term fix was to set the Greek codepage bit in the font (in addition to the ones that were already legitimately set) even if that font did not really have any Greek characters, so Mac OS X and Adobe apps would start counting the font as a “three-or-more-codepage font” and therefore place it in the Western section of the menu.

Incidentally, because the early Adobe fonts DID set the Greek bit “overenthusiastically” as Thomas just described, this misbehavior of the Adobe and Apple applications largely went unnoticed in the initial phase. I also believe that the more recent versions of Adobe apps and Mac OS X are behaving more rationally, so the fonts are listed in the Western menu section more easily, without forcing the font vendor to resort to tricks such as setting fake Greek bits.

[Yes, this was fixed quite a few years ago, so I don't think there is any remaining reason to set the bits incorrectly. - T]

]]>