Phinney on Fonts

Greek Support in Fonts: Truth & Lies

Written by

Thomas Phinney

in

A recent thread over on Typophile prompts me to explain why one sometimes sees OpenType CFF fonts that don’t actually support Greek, claiming that they do (by means of the Unicode Range and Codepage bit settings).

Originally, when Adobe converted the Adobe Type Library to OpenType, in the early stages we were thinking we wanted to be as compatible as possible with the Type 1 versions of the fonts.

In the absence of codepage bits and the like in Type 1 fonts, Windows GDI used to do a test for specific codepoints in the font to determine whether given codepages were supported, I believe one codepoint per codepage. I believe the codepoint to determine Greek support was the one for the “mu”… but it was definitely a test for a character that was present in the basic ISO-​Adobe character set (now Adobe Latin 1). This even though the character set didn’t really support Greek, it just had a few Greek characters because of their use as math symbols.

So, the Type 1 fonts were (arguably erroneously) detected as supporting Greek by GDI. The idea at the time was that the OpenType fonts with the equivalent character set should behave the exact same way, and therefore the determination of whether to give them the flag saying they support the Greek codepage should be based on the same test… so basically all the fonts would claim to support Greek, even though they really didn’t.

Somehow, even though the idea of near-​perfect compatibility between the OpenType fonts and their Type 1 predecessors was abandoned, this principle stuck during the initial conversion of the Adobe Type Library (“Alchemy”). Unicode ranges were set more-​or-​less in compatibility. Additionally, the AFDKO “makeOTF” tool used to build fonts would automatically do this, unless specifically over-​ridden. So you could see third-​party fonts doing this as well if they were made with older versions of Adobe tools.

I thought this was a mistake, and eventually convinced other folks of my opinion, so this decision was changed in the revision of the Adobe Type Library (“Facelift”) a couple of years ago, released about October 2007. The AFDKO was changes as well, to match this new preferred behavior.

So, you’ll find that the 1.x version of Adobe Caslon Pro built in 2001 has bits set to claim it supports the Windows Greek codepage and the Greek Unicode range, but this claim was dropped in the 2.0 version of 2007.

Comments

One response to “Greek Support in Fonts: Truth & Lies”

  1. Adam Twardoch

    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]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

More posts