Note that the UNICODE options only work on NT/2000 boxes.
A few other notes on this topic:
1. English is actually a special case. You can almost always display
English plus some other language (provided that by "English" you mean
*strtictly* ASCII text). All of the code pages on Windows contain these
If you really mean to support code page 1252 (e.g. accented characters,
typesetter's/curly/smart quotes, etc.), then you will face the issue John
2. You can install Code Page 932 on English NT machines (and code page
1252 on Japanese ones) from the LANGPACK directory. However, the default
behavior of the system is to convert strings to the code page of the
display (the system locale determines that). If you are seeing question
marks (on English) or underscores (on Japanese) instead of your
characters, you have a bad character conversion taking place. And no
amount of font changing will fix it.
If you see hollow or black rectangles where your characters should be,
*that* is a font problem.
You are far more likely to be seeing question marks than boxes. As John
points out, using the UNICODE option in your program will result in black
boxes instead of question marks (I am *vastly* simplifying here).
3. You don't say how you are displaying the characters either. If your
problem is with dialogs and strings stored in your resource files, you
should note that the RC file must contain a character set identifier (look
for "1252" in your English file) in order for the resource compiler to
correctly interpret the characters. Not making the proper changes to the
resource file could result in a faulty conversion (and thus funny-looking
While I'm on the topic, note that font metrics differ between Windows
platforms. If you expect to run on Win9x, stretch your dialogs on
Win95-Japanese (is the last I heard on this topic).
4. If your program blows up when setting the font (or the font change
doesn't seem to have any effect on the display), you may not be setting up
the logical font structure properly. I could probably look up which fields
need to change--there's a character set identifier that is 0 for CP1252
and 128 for Asian fonts--but Bill Hall is forever telling me that it is
better to make the user choose from a Font selection dialog (and let the
system fill it in for you)... if it isn't too disruptive to the user
interface, you might consider that as a solution (your users can make
better choices abuot their configuration than you can do
Addison P. Phillips Principal Consultant
Inter-Locale LLC http://www.inter-locale.com
Globalization Engineering & Consulting Services
+1 408.210.3569 (mobile) +1 408.904.4762 (fax)
On Thu, 20 Jul 2000, John O'Conner wrote:
> pierre vaures wrote:
> > To Whom It May Concern:
> > We develop, on NT4 using Visual C++ 6.0, an international application for
> > Japanese
> > and US users.
> > We need to display both English and Japanese (Kanji, Hiragana, Katakana)
> > characters.
> > We don t find a font able to display both, in particular on NT US.
> > If you have any information, or ideas, thanks for your help.
> Even if you have an appropriate font containing Japanese characters, you may
> still have a problem displaying both at the same time on an US English NT
> system. Is your application compiled as an "ANSI" or "UNICODE" application?
> The distinction is important because of the following:
> 1. So called ANSI applications use a legacy charset, ie CP 1252 or CP 437 or
> CP 850 in the US, for most text handling components. Throwing Japanese SJIS
> text at a component that only understands CP 1252 results in garbage on the
> display of some text fields and areas.
> 2. Compiling your app as a UNICODE application means that all Win32 API calls
> use Unicode-enabled versions of the API. Text areas expect you to pass
> Unicode, and it displays correctly when an appropriate font is used.
> -- John O'Conner
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:06 EDT