They don't [font] associate with font linkers, among others

by Michael S. Kaplan, published on 2007/07/11 18:33 -04:00, original URI:

Back in this post and this other one, I have been kind of hinting around at the functionality known as FONT ASSOCIATION.

Now in the post you are reading, I am going to explain what it is.

First we'll go with a dictionary definition. I'll go with the American Heritage definition since the book is close by:

Association (n, ə-sō'sē-ā'shən) -- An organized body of people who have an interest, activity, or purpose in common; a society.

One thing you notice about many such associations is a sense of exclusivity -- by joining the association you get privileges that others do not. But the members themselves are quite independent and have their own purposes and goals.

Well, font association fits into this kind of definition quite well. :-)

Basically, to join the association, you must

  1. be a font (duh!), and
  2. be used on a machine with a Chinese, Japanese, or Korean system locale, and
  3. have font association initialized (as discussed here)

If you meet these guidelines, then GDI will have a general preference for the preferred font of the main script of the particular East Asian locale (e.g. SimSun for Simplified Chinese, Gulim for Korean and so on).

And this association will happen even if one does not use a font in the GDI font link chain, which one cannot always rely on otherwise. If it is not turned on then people who are used to it will complain about the bug they hit, and sometimes if the characters are not in the font given to them by their "association" then they will get NULL glyphs rather than characters.

And once again the LOGFONT lfCharSet member becomes the only way one can break out of the association for a little while (unless your  font already supports the script, of course). Basically one is better off if one sets the lfCharSet to something that you are sure does not contain the characters, the only good escape here.

Note also from that second post that Gulim has font linking behavior when Korean is the default system locale. But like all good associations, the Fellowship of the Font Linkers are not their partners, and the font link chin that exists for a given font is not respected if the font is chosen through association....

That is font association -- a legacy technology that leads to a specific popular behavior that customers in East Asia may be relying on now -- so we are kind of stuck with it. Even if it can often be lousy....

I wish we didn't, and that I could say "I don't associate with those kinds of fonts anymore."


This post brought to you by (U+b36f, a.k.a. HANGUL SYLLABLE TIKEUT EO HIEUH)

# Mihai on 11 Jul 2007 7:15 PM:

"they will get NULL glyphs rather than characters"

I assume you are talking about "NOTDEF glyphs" (

Sorry, I am not nitpicking, just trying to help you get rid of that habit :-D

(and I have to admit, I need that too)

# Michael S. Kaplan on 11 Jul 2007 7:24 PM:

i will probably keep calling them NULL glyphs most of the time, since more people know of that than .notdef.

But yes, you are right. How can I disagree when you cite me in support of your argument? :-)

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2008/02/29 A more definitive definition of[ Font ]Association (a technology that helps us put the backward in backward compatibility!)

2007/10/25 Is it a Unicode issue? A non-Unicode issue? What the hell is it? (aka Beware former [Font ]Associations)

go to newer or older post, or back to index or month or day