Fonts that are 'fixed-width' even if they do not claim to be

by Michael S. Kaplan, published on 2005/09/11 23:30 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/09/11/463672.aspx

When you obtain a font in Windows (whether by CreateFont, CreateFontIndirect, CreateFontIndirectEx, any of the font enumeration functions, or whatever your preferred method is), you will almost always have the option of asking for a FIXED_PITCH font in the fdwPitchAndFamily member. The purpose of this is to give you a font with fixed width letters, such as the inestimatable Courier New. The most striking characteristic of these fonts is that every letter has the same width, from the very thin lowercase i to the thickest uppercase W.

Now of course there are many complex script languages that can be quite a challenge when it comes to designing a fixed width font due to the re-ordering, shaping, and/or stacking behavior in the underlying script, but that can be a topic for another day....

Today I am going to talk bout a whole class of fonts that are fixed width in a different way -- some of the fonts for Chinese, Japanese, and Korean. They cannot be requested via a FIXED_PITCH since they are technically not fixed width fonts -- they have two widths:

• One for "full width" characters such as ideographs, Hangul, Jamo, Kana, and full width letters and digits;
• One for "half width" characters such as all of the non-ideographic language characters and the halfwidth Jamo and Kana.

By convention, the characters in the full width category are twice as wide as those in the half width category, and as far as I know there is not an intrinsic property of fonts that identifies these "split level" fixed width fonts.

As I mentioned here and here, while this was once more of a legacy, encoding based issue (the half width characters were literally the one-byte characters in an otherwise double byte code page for languages like Japanese and Korean), this is obviously no longer the case in Unicode (where all of the relevant characters will need the same number of bytes). However, it is very much an aesthetic issue, where in many contexts characters such as the full width Katakana are described as less pleasant visually.

The first time I ran across that particular issue is when I was working on the Microsoft Access team, where all of the Access property descriptions are listed twice. These dual descriptions are identical for almost all languages but in Japanese the strings that show up in the property sheet use halfwidth katakana, while in other places the fulldwidth katakana strings are used. At the time I asked why they did not just use LCMapString to convert the string, and it was pointed out to me that this would potentially convert ASCII letters, digits, and punctuation to their fullwidth equivalents, which was not really a good idea....

(As an aside, Jesper Holmberg once told me a story about a localizer who found that none of the inserts were working in strings after they were localized for a managed application. It turns out that they were taking the curly braces used for the inserts (e.g. {0}, {1}, etc.) and converting them to their full width equivalents, converting U+007b and U+007d to U+ff5b and U+ff5d. No wonder the inserts did not work!)

Anyway, I thought about posting all of this after reading the post that Buck Hodges did earlier on figuring out how wide is a string when displayed in the console window, which is a practical application of when you may well need to know this information. Note Buck's final function:

    static int CalculateConsoleWidth(String text)
    {
        Encoding encoding = Console.Out.Encoding;

        if (encoding.IsSingleByte)
        {
            return text.Length;
        }
        else
        {
            return encoding.GetByteCount(text);
        }
    }

Funny how it ends up using those encoding roots where this half/full width stuff all started, huh? :-)

This post brought to you by "｛" and "｝" (U+ff5b and U+ff5d, a.k.a. FULLWIDTH LEFT AND RIGHT CURLY BRACKETS)

# Dean Harding on 12 Sep 2005 3:05 AM:

# Rosyna on 12 Sep 2005 6:41 AM:

# Michael S. Kaplan on 12 Sep 2005 6:56 AM:

# Mihai on 12 Sep 2005 12:33 PM:

# Rosyna on 12 Sep 2005 12:34 PM:

# Michael S. Kaplan on 12 Sep 2005 2:32 PM:

# Mihai on 12 Sep 2005 5:31 PM:

# kurakuraninja on 13 Sep 2005 3:17 AM:

Sonja on 25 Apr 2010 12:17 AM:

referenced by

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