FW: Unicode Web pages

>>[From:	Misha Wolf [SMTP:misha.wolf@reuters.com]]
>>[Sent:	Thursday, February 06, 1997 7:32 AM]
>
>>>> <http://www.microsoft.com/msdownload/ieplatform/iewin95/18.htm>
>>>
>>>These work excellently, for the most part, with MSIE 3.0.  After
>>>loading them, I could view the separate announcements in Simplified
>>>and Traditional Chinese, Japanese, and Romanian.  However, the Russian
>>>page didn't work at all, and I'm not sure why.  The Central European
>>>service pack includes several Cyrillic fonts, which I believe are
>>>encoded as ISO 8859-5, but MSIE 3.0 doesn't appear to recognize that
>>>encoding declaration.  It also can't deal with the all-language pages
>>>in either UTF-8 or NCRs.
>
>>IE 3.0 supports neither ISO 8859-5 nor Unicode.  Both of these will, 
>>I hope, be supported by IE 4.0.
>
>You can assume that.
>
>>>Does anyone have an explanation of how MSIE is able to convince the OS
>>>to deal with these encodings, especially the non-8859 ones?  WordPad
>>>can differentiate between the differently encoded fonts, but Word
>>>doesn't even get that far.  I'd like to be able to take advantage of
>>>this capability, but I can't figure out what it's doing.  More
>>>monopolistic practices, I suspect...
>
>The Multilanguage Support installs the appropriate code page on your system
>plus a font that contains the necessary glyphs. The content of the
>Pan-European Support package is essentially the same as what gets installed
>when using Win95's Multilanguage option in Win95 SETUP. The content of the
>Asian Multilanguage support files is the Windows codepage for that region
>plus a font. The code pages of all the Multilanguage support packs installed
>are accessible to everyone via Win32 APIs that take code page IDs. Working
>with all European, Cyrillic, Turkish and Baltic characters is possible using
>any standard Win32 API.
>
>However, to output Chinese or Japanese or Korean characters on a non-native
>Windows 95, you need to use Win32 Unicode APIs.
>
>Here is a piece of text from the Globalization Resource Kit of the Microsoft
>Developer Network CD that explains which those are:
>---------------
If you want to base your application on Unicode and run it on Windows
95, you need to translate string parameters to local character sets
before calling API functions. (The only wide character APIs that handle
Unicode on Windows 95 are TextOutW, ExtTextOutW, GetCharWidthW,
GetTextExtentW, and GetTextExtentPointW.)
The API for translating strings from Unicode into the system's default
local character set is WideCharToMultiByte. When you receive
string-based information from Windows 95, you need to translate it into
Unicode by calling MultiByteToWideChar before working with it.
Obviously translating strings to and from Unicode every time you call an
API that takes string parameters adds overhead to your program. It's up
to you to weigh the pros and cons of this approach to suit your
program's requirements.
---------------
It is all documented somewhere, sometimes it is just hard to find...

Chris Wendt
Program Manager, Microsoft Corp.

Received on Thursday, 6 February 1997 15:26:52 UTC