Neither GDI nor Uniscribe solve the ultimate font problem completely, either

by Michael S. Kaplan, published on 2006/06/16 10:35 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/06/16/634124.aspx

I have not been shy about criticizing stuff provided by the Windows Shell in the past, but it is not entirely fair to put the burden of logical fonts upon them like I did in this post and this one a few days ago. I mean, stuff like DEFAULT_GUI_FONT actually comes out of GDI technically, and even though I have been referring to logical fonts as "the Shell solution" it would probably be more accurate to refer to them at this point as "the former UI solution provided to the Shell".

But as I pointed out in those two posts, the logical fonts make up a bizarre edge case that is only even possibly relevant to the Shell which has some serious implementation flaws and which is not used consistently even in the cases where the flaws have no negative impact.

So if the simple scenario's solution was not implemented or used effectively, how about the more complex scenario of supporting any supported language in any control? Is there any hope that this will work?

In the world of GDI and Uniscribe, this is handled mostly within the realm of font linking and font fallback, which I have discussed previously. And while it is true that the line between when each is used has become much more blurred lately (not to mention the further blurring caused by the fact that supplementary characters are treated as "complex" and handled via Uniscribe rather than GDI as well!), the truth is that usually one only notices the difference between them in two cases:

For the second point -- to be fair to Uniscribe and its logic, the job it is tasked with is much more difficult -- scaling between two different CJK fonts is always going to be fundamentally easier than scaling between fonts handling two scripts (like e.g. Cyrillic and Tibetan) that can have such different typographical attributes like baseline and charcter height.

Even within a single font like Tahoma, the mixing of scripts like Latin, Hebrew, Arabic, and Thai can lead to so many bizarre scaling issues that making them all look consistent next to each other:

can make people who use a script feel like the rules about font size and shape cause their script to be distorted in the name of cross-script consistency. This is in fact one of the reasons that people look oddly at for example the Arabic script in Tahoma versus Microsoft Sans Serif versus Times New Roman:

Which is nothing compared to the issue of (e.g.) Latin vs. Tibetan, where the choice seems to be either illegible Tibetan or way too big Latin, or

This example will of course only be meaningful if you have support for Tibetan on your machine, so here are some screenshots in Vista:

(In that screenshot, the difference is between Lucida Console size 10 versus size 18!)

Well, clearly some more work to scale between scripts automatically is needed when one crosses font boundaries. And rather than having to memorize a set of rules about the minimum acceptable and preferred sizes for scripts in different fonts, having some built-in work for a developer to use ONE size that would mean "appropriate size for the script" would definitely be prefetred.

Attempts at solutions here like the Microsoft Word 2003 three font name/size settings solution have some pretty significant limitations:

Not the least of which is the real differences between the scaling of all of the different complex scripts!

We finally start to get to the area of resizable dialogs that everyone has wanted to get into so much -- although note that this does nothing for the real problems here of what should the size actually be, not to mention the fact that the only real problem that is solved by autolayout in this context is avoiding clipping, which is really only a problem that is at its most seriousness in cases where the font may well be in part way to freaking big!

Let's add to that the problem that in controls for user input, one cannot dynamically change all the characteristsics of a dialog based arbitrarily on what a user types. Thus for the generic problem we are talking about here, autolayout will not really solve any of the real problems that we face....

Now there is already, even ignoring different languages, real complexities in font size as defined in a LOGFONT (as I discussed previously). So it is very possible that anyone who suggests that single special way to create a font that would not force a developer to keep track of the complex size issues will be summarily shot at sunrise (or fired?), but maybe that is what is needed here -- if Uniscribe can keep track of all of the sophisticated rules related to changing the font NAME based on the script then perhaps it can as its next challenge take up the changing of the font SIZE so that it can happen just as automatically.

Or maybe something like what is in WPF (a.k.a. Windows Presentation Foundation, a.k.a. Avalon) is needed. This is the topic of a future post in this series, coming soon.....

OK - so why are some fonts so much smaller than others at the same "size"?

With the "The People's Republic of China" shots that you have, the Tibetian font appears to fit most of the body each glyph inside half the x-height, ascenders into the whole x-height, and not using at all the space between the x-height and the ascent of the Latin font.

I'd always figured that all fonts of a given size /should/ have the same ascent. (Or possibly x-height instead) From the Tibetian font, is this not the case? Or does it have some glyphs that have "super-ascenders" that need more space, requiring the rest of the font to be shrunk?

(Semi-OT, is it possible for individual glyphs to draw outside the font's body size?)

Hi Adam,

The problem here specifically in the Tibetan case is that those are not single letters -- they are multiple letters stacked. Height becomes a very interesting thing when it involves some of the same features as width in relation to word progression!

But in the general case, there is no specific scaling rule related to how fonts that requires a specific size to fit characters within; these issues are within the decision making of the typographer.

Now Tahoms is a good exasmple of a font that tried to scale everything across scripts, but masny people feel that this was done at the cost of the quality of some of them. If a task is impossible within fonts, how can it work between fonts? :-)

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.