Font Substitution MS Shell Dlg

[Brent]

The code base I'm working on uses MFC resources that define the Font
for Dialogs to MS Shell Dlg, on most machines this ends up running
through the Font Substitution settings and receiving Microsoft San
Serif.
On a Chinese Windows install, the substituted font is SimSun. Looking
at the registry values for Font Substitution, the substituted font
should still be Microsoft San Serif.

Where might the Font Substitution values be coming from?

The text we are printing is all in the 1252 code page. (We have not
localized for Chinese, yet). The current issue is that our Dialog
text is being crop due to the large difference in font width between
San Serif and SimSun.

[Norman Diamond]

There are 101 registry keys that define various kinds of font substitutions
for various purposes.

If you are sure that your dialog text will use only code page 1252, and if
you want to use a font that cannot display things like the user's filenames
or the user's own name, then you don't even want to use MS Shell Dlg in the
first place. In this situation you want to specify the font as Microsoft
Sans Serif or Tahoma or whatever makes sense to you.

But if there's any chance that your dialog text might someday include an
error message text retrieved from inside Windows, or a Cancel button from
the MFC library, or anything like that, then you want to use the executing
system's standard fonts and you want to size your controls so that the texts
will fit.

"Brent" <brent...@gmail.com> wrote in message
news:1190490900.7...@k79g2000hse.googlegroups.com...

[Michael S. Kaplan [MSFT]]

What is happening here as nothing to do with font substitution, but is you
use MS Shell Dlg then you are REQUESTING to get the default font that
Windows deems appropriate for your settings, which means if there is
clipping you have not prepared the dialog text to fit with your requested
settings.

In summary, don't order the five star Thai food if you don't want the
spiciness, and don't specify the "put in the font you want" font if you
don't want it either....

--

MichKa [Microsoft]
Fundamentals Technical Lead
Windows International
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.

"Brent" <brent...@gmail.com> wrote in message
news:1190490900.7...@k79g2000hse.googlegroups.com...

[Norman Diamond]

A few days ago I observed another situation where your company obeyed that
rule. When your colleagues developed a file transfer utility for customers
to get downloads from MSDN and other sites, they knew they didn't want a
font that could display folder names where customers would get downloads
from MSDN and other sites. So the file transfer utility displays mojibake
instead.

Please teach your colleagues that if they prevent Thai people from ordering
Thai food and prevent Chinese people from ordering Chinese food etc., your
colleagues cause a lot of starvation. I wish there were a way for your
colleagues to understand this starvation themselves, but unfortunately too
many fonts handle codepoints 0x20 to 0x7E with too much success for that.

Of course some situations are exactly the opposite. Today I saw a web page
with a lot of garbage unreadable Kanji, because the site's owner didn't want
to specify that his character set wasn't Japanese. In a situation like
that, where the developer really does write 100% of the text that will be
displayed, the developer should specify their own character set and font
instead of setting it to be the viewer's default. But I don't think this is
the situation of the original poster in this thread, since this is a
programming newsgroup not a web site newsgroup.

"Michael S. Kaplan [MSFT]" <mic...@online.microsoft.com> wrote in message
news:uPUNIKDB...@TK2MSFTNGP05.phx.gbl...