tfaghihi wrote:
>... The character cell with decimal code 183 has different
behaviors in Windows 95 and Windows NT. In Windows 95 it is
mapped to the Unicode index 22C5h, but in Windows NT it is
mapped to 00B7h.
Murray Sargent wrote:
>I'm curious too. Which code page did you use on your Win95
and WinNT computers? The system mapping function is
MultiByteToWideChar() and for all the codepages 1250 - 1258,
Win9x and WinNTx map 183 (0xB7) to 0xB7 (MIDDLE DOT)...
Here's the solution to this puzzle.
I'm assuming that, when the original author (tfaghihi) said
"code 173" that they really meant "code 183"; that seems to be
consistent with the latter part of the original message.
We have known for some time that, if you draw text using
TextOutA with a LOGFONT that has the charset set to
ANSI_CHARSET, you don't get the same results as you would by
calling MultiByteToWide with codepage 1252 followed by
TextOutW. In particular, TextOutA will map xB7 to U+2219
whereas cp1252 via MultiByteToWide maps xB7 to U+00B7.
A couple of other differences:
MultiByteToWide (cp1252):
up to Win 95 (prior to euro patch), NT4 (prior to SP4)
x80 -> U+0080
x8E -> U+008E
x9E -> U+009E
Win 95 w/ euro patch, NT4 SP4, Win98, Win2000
x80 -> U+20AC
x8E -> U+017D
x9E -> U+017E
But...
TextOutA (charset = ANSI_CHARSET) -- *all* versions (including
Win98)
x8E -> U+008E
x9E -> U+009E
Apparently, xB7 has a long and sordid history marked by
inconsistent implementations both in fonts and in software. For
example, a little experimenting will reveal that Word 97 does
some interesting things with xB7. (I'll leave it as an exercise
to the most interested readers to identify the symptoms.) We
can't be too harsh on the engineers, though: they were trying
to find the best solution for a long-standing problem.
We have discovered that x8E and x9E (via cp1252, U+017D and
U+017E) appear to be starting to develop some history of their
own. In addition to the different mappings indicated above,
we've found some extraordinary handling of these two codes in
MS Publisher 98 and Publisher 2000. (Again, as an exercise to
the most interested readers, find out the symptoms.) I can only
assume that the engineers did what they did because they knew
there would be a lot of fonts out there that don't have glyphs
for U+017D and U+017E, and they wanted to provide a workaround
so that users would get the characters they'd expect.
I hope this answers more questions than it raises!
Peter
From: murrays@microsoft.com AT internet on 08/11/99 08:16 PM
Received on: 08/11/99
To: Peter Constable/IntlAdmin/WCT, unicode@unicode.org AT
internet@Ccmail
cc:
Subject: Re: character 173
I'm curious too. Which code page did you use on your Win95 and
WinNT computers? The system mapping function is
MultiByteToWideChar() and for all the codepages 1250 - 1258,
Win9x and WinNTx map 183 (0xB7) to 0xB7 (MIDDLE DOT). To see
these mappings and some common DBCS mappings as well, click on
http://www.microsoft.com/globaldev/reference/WinCP.asp.
Murray
> -----Original Message-----
> From: mohrin@sharmahd.com [SMTP:mohrin@sharmahd.com]
> Sent: Tuesday, August 10, 1999 8:56 AM
> To: Unicode List
> Subject: Re: character 173
>
> On Mon, 9 Aug 1999 21:22:58 -0700 (PDT), faghihi wrote:
>
> >The character cell with decimal code 173 has problem in
Windows 95 .
> where
> >mapped to the Unicode index?
> >for example The character cell with decimal code 183 has
different
> behaviors
> >in Windows 95 and Windows NT. In Windows 95 it is mapped to
the Unicode > >index 22C5h, but in Windows NT it is mapped to
00B7h.
>
> I'm just curious: what do you mean by "In Windows 95 it is
mapped..."? > How does this problem manifest itself?
>
>
> --
> Torsten Mohrin
> Sharmahd Computing GmbH, Hannover, Germany
> Phone: +49-511-13780, Fax: +49-511-13450
> http://www.sharmahd.com, mohrin@sharmahd.com
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:51 EDT