Unicode and CP_SYMBOL question.

[Rein Klazes]

Hi,

Trying to fix a problem with Win2K's charmap.exe, I have a question for
the unicode experts.

If I convert character code's 32 to 255 using codepage SYMBOL on a Win2K
system, like in this snippet:

char c;WCHAR w;
for( c = 32; c; c++)
    MultiByteToWideChar(CP_SYMBOL,0,&c,1,&w,1);

I get that w == c + 0xf000

( codes 0-31 are unchanged, any flag setting makes the function fail).

Wine's implementation of MultiByteToWideChar() does something quite
complicated based on standard unicode tables and returns Unicode
characters in all kind of ranges.

The loop above is basically what Win2K's charmap.exe does. Of course it
does not properly display symbol fonts like "Symbol".

Is there any reason why in this case MultiByteToWideChar should not do 
w = c + 0xf000 ?

Rein.

Unicode and CP_SYMBOL question. [?? Probable Spam]

[Dmitry Timoshkov]

"Rein Klazes"  wrote:
> Wine's implementation of MultiByteToWideChar() does something quite
> complicated based on standard unicode tables and returns Unicode
> characters in all kind of ranges.
>
> The loop above is basically what Win2K's charmap.exe does. Of course it
> does not properly display symbol fonts like "Symbol".
>
> Is there any reason why in this case MultiByteToWideChar should not do 
> w = c + 0xf000 ?

Wine is using the following source for its Symbol to unicode map:
ftp.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/symbol.txt

Apparently Windows uses something different. Probably we have to change
our internal map for Symbol encoding since we are doing already something
similar to your findings in dlls/gdi/freetype.c,FT_UInt get_glyph_index().

Unicode and CP_SYMBOL question. [?? Probable Spam]

[Rein Klazes]

On Thu, 15 Jan 2004 16:20:28 +0800, you wrote:

[?? Probable Spam]

Your spam filter needs to be educated about wine-devel ;-)
> > Is there any reason why in this case MultiByteToWideChar should not do 
> > w = c + 0xf000 ?
>
> Wine is using the following source for its Symbol to unicode map:
> ftp.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/symbol.txt

Yes, I've seen that, it is pity that Windows seems not to use it.
> Apparently Windows uses something different. Probably we have to change
> our internal map for Symbol encoding

I will try a few other Windows versions first. It looks to me that
Symbol encoding is not a real encoding at all apart from the 0xf000
offset. calls like GetCPinfo(CP_SYMBOL,...) also fail on Win2K, probably
for that reason..
> since we are doing already something
> similar to your findings in dlls/gdi/freetype.c,FT_UInt get_glyph_index().

Yup, that is, I think, because it needs to work for non Unicode
characters as well.

Rein.

Unicode and CP_SYMBOL question. [?? Probable Spam]

[Dmitry Timoshkov]

"Rein Klazes"  wrote:
> [?? Probable Spam]
>
> Your spam filter needs to be educated about wine-devel ;-)

That's not my spam filter (it behaves differently), some host in
e-mail chain marks every e-mail from you on this list with that
addition in the subject line.
> > Apparently Windows uses something different. Probably we have to change
> > our internal map for Symbol encoding
>
> I will try a few other Windows versions first. It looks to me that
> Symbol encoding is not a real encoding at all apart from the 0xf000
> offset. calls like GetCPinfo(CP_SYMBOL,...) also fail on Win2K, probably
> for that reason..

Sounds like a good idea. Please test and report here what you will find.

Unicode and CP_SYMBOL question. [?? Probable Spam]

[Rein Klazes]

On Thu, 15 Jan 2004 19:24:25 +0800, you wrote:
> > > Apparently Windows uses something different. Probably we have to change
> > > our internal map for Symbol encoding
> >
> > I will try a few other Windows versions first. It looks to me that
> > Symbol encoding is not a real encoding at all apart from the 0xf000
> > offset. calls like GetCPinfo(CP_SYMBOL,...) also fail on Win2K, probably
> > for that reason..
>
> Sounds like a good idea. Please test and report here what you will find.

It works as I described on everything from Win2K up to a recent
Longhorn.
On everything below that (NTx and win9x) the call fails.

Further observations are that WideCharToMultiByte does the inverse (map
0-0x1f and 0xf020-0xf0ff, fail on everything else)  and that
EnumSystemCodePages() do not enum this code page (it does on wine).

I am planning to create a patch that fixes MultiByteToWideChar and
WideCharToMultiByte, as well as removing the symbol code page from the
code page table.

Rein.

[Dmitry Timoshkov]

"Rein Klazes"  wrote:
> I am planning to create a patch that fixes MultiByteToWideChar and
> WideCharToMultiByte, as well as removing the symbol code page from the
> code page table.

Please don't forget to remove the special case for CP_SYMBOL
in dlls/kernel/locale.c,IsValidCodePage() as well.