Is this the Über-font post? No, but it is the teaser for it!

by Michael S. Kaplan, published on 2006/06/06 05:01 -04:00, original URI:

What do this question from flyingxu:

I'm an MFC programmer. When I try to write some app for Chinese or Korean, I find many controls' size are changed by theire font. I mean, when I change the font, child dialog's size change and the whole dialog's layout is changed, which may lead to some overlap or empty space gap. It's big headache for me now.

and this question from Steffen (a.k.a. The SZ):

In your "What about logical fonts? " post you are writing much about shell dlg and shell dlg 2 and stuff. There are also a lot of other stuff outthere, but i still don't know what I should do. My requirements are pretty simple:
* windows 95 to vista support in single binary
* best ui experience which is available on this platform
* different dpi setting support
Thats all.

Currently I'm using FindResourceEx and mofiy the font name to "MS Shell Dlg 2" if available, if not using "MS Shell Dlg".

Why supports "MS Shell Dlg" not different dpi settings? (120dpi) (The font is not getting larger)

Will vista finally map "MS Shell Dlg 2" to "Segoe UI"? Or do I have to do this?


and this question from Matt:

On my dev box I’m running XP and the default font for my winforms is “Microsoft Sans Serif, 8.25pt” and it appears to match the font of other apps such as Excel and Outlook.  When my app is installed on a box running Vista, the font no longer matches Vista’s default font of Segoe.

What are the recommendations for an app to match the system font defaults?  Any links to code samples?

and the following blog posts:

and what Mark mentioned:

The problem is not in coming up with the function but in understanding what the rules are across themes and across different language versions of Vista. Does the font change for different themes? Does the font change across language versions?

This, in my experience, has always been the problem, trying to understand what the right thing to do is based on MSDN is virtually impossible. There is a stack of conflicting and (sometimes plain bad) information spread across many different locations. It would be refreshing to see guidance that states clearly what font should be used where.

have in common?

Well, first of all they all talk about fonts, obviously. :-)

What is more important is that there is in the heart of each post, each question, and each comment a common desire.

Simply stated? It is the desire for some magical way to simply not have to worry about choosing a font or its size to get the appropriate display of the text in an application.

So, watch this space because in approximately 24 hours I will post my ultimate response to all of this. You may disagree with it, you may wonder why someone who would post something like this would think he was even qualified to try, you may think it is the coolest thing since sliced bread.

But you'd probably be wrong, it is just gonna be about fonts. :-)


This post brought to you by ʬ (U+02ac, a.k.a. LATIN LETTER BILABIAL PERCUSSIVE)

# Adam on 6 Jun 2006 11:09 AM:

Oh for Avalon.

MS really ought to have produced an automatic-layout engine that sizes controls, their parents, and their containing windows based on the data actually in them by now. Nearly every other widget/window toolkit in existence has done this for ages, and it makes changing fonts/text (for l10n)/themes (widget decoration)/screen resolution/etc... completely automatic and hassle-free.

QT and GTK+ have had this for about 9 years. XUL's been doing it for 4 or 5.

# Michael S. Kaplan on 6 Jun 2006 11:32 AM:

Hi Adam,

I know that the whole "size matters" thing is a cliche; in this case it is definitely not true, since in most cases size is NOT the problem. It is actually deciding what font to use that is the main concern....

# Adam on 6 Jun 2006 12:08 PM:

Really? The first comment you quote seems to be entirely about the fact that the layout changes badly in response to font changes, the second seems to be quite a bit about a lack of scaling issues on hi-res screens.

As far as I can tell, a lot of apps have hard-coded fonts for things like dialogs and custom message boxes because font changes mess up the layouts. This appears to be what the third referenced comment is talking about as well.

In my experience, with a pixel-based layout engine, developers are almost forced to hard-code font faces and sizes instead of going with a generic one (e.g. "windows font", "menu font") so that things don't end up the wrong size and overflowing their boxes (or with acres of empty space around them) if the user has a different font/theme selected.

If Windows had an automatic layout engine that reflowed everything for you, that would pretty much eliminate these problems and allow controls to just pick up the users' preferred font face and size and DTRT.

# Michael S. Kaplan on 6 Jun 2006 3:54 PM:

Well, I both agree and disagree with you, for reasons that will be covered in the actual post....

But as I said, it is much more an issue that comes up due to changing scripts/languages automatically getting or desparately needing different sizes -- something that is in the end language based.

I am not trying to solve the generic GDI issue -- I am talking about the internationalization issue -- which is only indirectly about size, and only since language can affect size.

You may want to nag a GDI person about the generic issue.... :-)

# Rune on 7 Jun 2006 5:29 AM:

I look forward to your über-font article, if it even answers half the questions raised, it is going to be interesting.

Our need is simple: We want our apps to look like other Windows apps. Our menu should use the same font as other menus. Buttons, comboboxes, etc... There shouldn't be font spaghetti across applications, yet this seemingly is what often happens because "MS Shell Dlg 2" is hardly self documenting. (e.g. what is the standard font size used by the system? I think someone said it is hard coded, but what happens when the user switches over to "large fonts"?)

Scaling can be left to the application developers, but only if the standard font issues are documented.

I'll be keeping my eyes peeled for your next installment! :)


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

2006/06/11 Why the Windows Shell can't provide the ultimate font solution for everyone (or even anyone!)

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