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:

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:

Oooh, now I understand! I saw his post in the main MSDN blogs feed, but I couldn't work out what it was trying to do...

Now it makes sense - the full-width characters actually take up two columns in the Console, so when you calculate how many columns a string is going to occupy, you need to count the full-width characters twice!

Thanks, Michael :-)

# Rosyna on 12 Sep 2005 6:41 AM:

This makes me think of something. What happens to fixed width fonts if the ideal metrics do no match the device metrics?

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

Excellent question, Rosyna -- obviously in such a 'negotitaion' the device metrics win since they represent the reality of what can show up on the screen. I wonder how often the font gets blamed in such situations for a lousy appearance?

# Mihai on 12 Sep 2005 12:33 PM:

CJKV typography is way more complicated than "boxes" and "half boxes." There are also proportional versions of the font (the MS Pxxx version in the MS fonts).
See Ken Lunde's "CJKV Information Processing" (ISBN: 1565922247)

Then, LCMapString can be used to convert only the Kana to the wide version. I did this for a lot of applications when MS changed the Windows UI from using the narrow kana (Windows 3.x) to wide Kana (Windows 95).

# Rosyna on 12 Sep 2005 12:34 PM:

Too often, honestly. However, it becomes REALLY murky when one version of a fixed width font looks great, but then a later version looks like crap because ideal is nothing like device and the snapping causes the fixed part to be lost. But was it because the font stopped lying about its metrics, changed its metrics, or just stopped caring? We need the tootsie roll owl to find that answer (or someone willing to go into all the font tables).

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

Mihai -- Yes, I know, but it all started when we talked about the console. ;-)

Rosyna -- But where is the owl?!?

# Mihai on 12 Sep 2005 5:31 PM:

MichKap -- Well, sometimes my posts are to make things clear (or fuzzy :-) for other readers, not for you :-)

# kurakuraninja on 13 Sep 2005 3:17 AM:

On Sunday night I posted about a small fact in CJK fonts, when I talked about Fonts that are 'fixed-width'...

Sonja on 25 Apr 2010 12:17 AM:

Is there a font that provides both East Asian and Latin characters in exactly the same width? For instance, I would want these three examples to line up perfectly:

漢字

ii

齉W


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

2012/08/14 Getting your spidey senses FIXED

2008/06/09 Did you lose some WIDTH or something?

2007/11/08 The [non-]progress of the über-fixed width fonts

2007/05/01 HALFWIDTH != Half the width

2007/04/23 How long is it in the console?

2007/03/28 Like Cartman, that 'W' letter isn't fat; it's big boned!

2006/08/23 What would a 'Kartika Fixed' font for Malayalam DO, exactly?

2006/05/09 The font width is broken? Well, fix it!

2005/09/13 One more thing about some of those CJK fonts....

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