Font for Japanese && US applications
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. Regards, __ Pierre Vaures email: [EMAIL PROTECTED]
RE: Font for Japanese && US applications
Pierre Vaures ([EMAIL PROTECTED]) asked: > 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. Microsoft supplies fonts that probably do what you want. MS Gothic is part of the Japanese language pack that should be on your NT 4 CD-ROM. You can also install it via Windows Update on the Tools menu in IE 5. MS Mincho contains more characters, and is supplied with Office 2000 and FrontPage 2000. You can find information about Unicode fonts that support particular languages and ranges at: http://www.hclrss.demon.co.uk/unicode/fonts.html http://www.hclrss.demon.co.uk/unicode/fontsbyrange.html Alan Wood (Documentation Writer / Web Master) Context Limited (Electronic publishers of UK and EU legal and official documents) mailto:[EMAIL PROTECTED] http://www.context.co.uk/ http://www.alanwood.net/ (Unicode, special characters, pesticide names)
Re: Font for Japanese && US applications
MS Mincho is actually on the NT4 CD in the \langpack directory. michka - Original Message - From: "Alan Wood" <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Cc: "'pierre vaures'" <[EMAIL PROTECTED]> Sent: Thursday, July 20, 2000 7:22 AM Subject: RE: Font for Japanese && US applications > Pierre Vaures ([EMAIL PROTECTED]) asked: > > > 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. > > Microsoft supplies fonts that probably do what you want. > > MS Gothic is part of the Japanese language pack that should be on your NT 4 > CD-ROM. You can also install it via Windows Update on the Tools menu in IE > 5. > > MS Mincho contains more characters, and is supplied with Office 2000 and > FrontPage 2000. > > You can find information about Unicode fonts that support particular > languages and ranges at: > http://www.hclrss.demon.co.uk/unicode/fonts.html > http://www.hclrss.demon.co.uk/unicode/fontsbyrange.html > > Alan Wood > (Documentation Writer / Web Master) > Context Limited > (Electronic publishers of UK and EU legal and official documents) > mailto:[EMAIL PROTECTED] > http://www.context.co.uk/ > http://www.alanwood.net/ (Unicode, special characters, pesticide names) > > >
Re: Font for Japanese && US applications
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
RE: Font for Japanese && US applications
> > Microsoft supplies fonts that probably do what you want. > > MS Gothic is part of the Japanese language pack that should be on your NT 4 > CD-ROM. You can also install it via Windows Update on the Tools menu in IE > 5. > > MS Mincho contains more characters, and is supplied with Office 2000 and > FrontPage 2000. > > You can find information about Unicode fonts that support particular > languages and ranges at: > http://www.hclrss.demon.co.uk/unicode/fonts.html > http://www.hclrss.demon.co.uk/unicode/fontsbyrange.html > Please note that Japanese machines name these fonts IN JAPANESE using multi-byte Latin-1 characters, so if you call them by name in your code, you will get different results on English and Japanese machines. Best Regards, Addison
Re: Font for Japanese && US applications
Yes, truly globalized applications must try the name both ways. I am glad they finally fixed this implementation problem in Windows 2000. michka - Original Message - From: <[EMAIL PROTECTED]> To: "Unicode List" <[EMAIL PROTECTED]> Cc: "Unicode List" <[EMAIL PROTECTED]> Sent: Thursday, July 20, 2000 9:27 AM Subject: RE: Font for Japanese && US applications > > > > Microsoft supplies fonts that probably do what you want. > > > > MS Gothic is part of the Japanese language pack that should be on your NT 4 > > CD-ROM. You can also install it via Windows Update on the Tools menu in IE > > 5. > > > > MS Mincho contains more characters, and is supplied with Office 2000 and > > FrontPage 2000. > > > > You can find information about Unicode fonts that support particular > > languages and ranges at: > > http://www.hclrss.demon.co.uk/unicode/fonts.html > > http://www.hclrss.demon.co.uk/unicode/fontsbyrange.html > > > Please note that Japanese machines name these fonts IN JAPANESE using > multi-byte Latin-1 characters, so if you call them by name in your code, > you will get different results on English and Japanese machines. > > Best Regards, > > Addison > >
Re: Font for Japanese && US applications
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 characters. 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 points out. 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 dialogs). 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 programmatically). Best Wishes, Addison === Addison P. Phillips Principal Consultant Inter-Locale LLChttp://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 > > >
Re: Font for Japanese && US applications
- Original Message - From: <[EMAIL PROTECTED]> > there's a character set identifier that is 0 for CP1252 > and 128 for Asian fonts 128 is only good for Japanese... the actual definitions for charsets are in wingdi.h in the Platform SDK, but you can use for DEFAULT_CHARSET and not worry about it anymore if you just need to support the system default lang. michka
Re: Font for Japanese && US applications
This is what happens when you don't refresh your memory by looking it up! Note that using DEFAULT_CHARSET uses the default system locale's code page. If you intend to load a font for Japanese on English Windows you have to fill in the font structure properly. Addison On Thu, 20 Jul 2000, Michael (michka) Kaplan wrote: > - Original Message - > From: <[EMAIL PROTECTED]> > > there's a character set identifier that is 0 for CP1252 > > and 128 for Asian fonts > > 128 is only good for Japanese... the actual definitions for charsets are in > wingdi.h in the Platform SDK, but you can use for DEFAULT_CHARSET and not > worry about it anymore if you just need to support the system default lang. > > michka > >
Re: Font for Japanese && US applications
At 08:17 AM 7/20/00 -0800, John O'Conner wrote: >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. Even if you don't compile an application as UNICODE you can make calls to the Unicode version of a Win32 API function by appending a W to the end of its name. This is a useful technique to allow programs for Win9x to access the half dozen API functions that are implemented for Unicode on that platform. When might you want to do that? For example if you write an editor. The low level text output functions support Unicode on Win9x, so you can write an editor that lets you display and edit Unicode text and support Unicode fonts quite easily. The same editor can run unchanged on NT. In the scenario I mentioned, Menus, Dialogs, etc. are still limited to what MS calls the "ANSI" character set on Win9x. On NT, you would need to use the Unicode version of these, which is easiest done by compiling the application with #define UNICODE. You can see how this leads to a hybrid design where the UI support might be separately compiled for NT and Win9x, but the 'engine' of your application resides in a DLL that, unencumbered by standard dialog controls, can be written in Unicode, still display data using Unicode and support a common file format for you application. MSJ publishes articles on this and related topics at regular intervals - check Microsoft's MSDN for this kind of information. Finally, there are commercially released libraries that will insert themselves between a UNICODE application when it's running on Win9x and redirect the API calls to the ANSI version of the API (they attempt to do a conversion of the text in the string parameters). This should work quite well, as long as the user on the Win9x system doesn't need to use non-native characters in dialogs or filenames. You might want to check out the "Cheops" product from Basis Technology http://www.basistech.com/products/Cheops.html A./
