Re: [try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

[Dmitry Timoshkov]

"Vitaly Perov"  wrote:
> Changed since last send: use mlang internal mlang_data structures instead of 
> static array.

You still haven't done the other part: use Win32 APIs EnumSystemCodePages/
GetCPInfo/WideCharToMultiByte instead of accessing Wine internals directly.

[try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

[Vitaly Perov]

"Vitaly Perov"  wrote:
> > It doesn't really matter what code pages Windows supports, it does
> > matter though what code pages are valid. You need to use Win32 APIs
> > EnumSystemCodePages/GetCPInfo/MultiByteToWideChar instead of accessing
> > Wine internals directly.
> I used EnumSystemCodePages before, but in this case GetCharCodePages set some 
> extra bits in result. So the result differ from Windows
> > ... or rather use mlang internal mlang_data structures.
> I's good idea! Thank you!

So, I use mlang_data[i].family_codepage as you adviced.
May be I misunderstood something?

[try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

[Dmitry Timoshkov]

"Vitaly Perov"  wrote:
> "Vitaly Perov"  wrote:
> > > It doesn't really matter what code pages Windows supports, it does
> > > matter though what code pages are valid. You need to use Win32 APIs
> > > EnumSystemCodePages/GetCPInfo/MultiByteToWideChar instead of accessing
> > > Wine internals directly.
> > I used EnumSystemCodePages before, but in this case GetCharCodePages set some 
> > extra bits in result. So the result differ from Windows

I can't read your mind or guess what those "some extra bits" are. Why can't you
mark the failing tests with todo_wine and think later how to make the tests pass?
> > > ... or rather use mlang internal mlang_data structures.
> > I's good idea! Thank you!
>
> So, I use mlang_data[i].family_codepage as you adviced.
> May be I misunderstood something?

Have you tried to do what I suggested?

Also you either need to send the test after the implementation, or add
todo_wine in appropriate places and remove them in the patch which makes
the tests pass.

[try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

[Vitaly Perov]

> I can't read your mind or guess what those "some extra bits" are. Why can't
> you mark the failing tests with todo_wine and think later how to make the
> tests pass?

This function must set only supported codepages bits
The supported codepages are: 
ttp://www.microsoft.com/globaldev/reference/WinCP.mspx

For example, we use a symbol from Latin1 codepage.
All codepages are include this symbol.
So if we use EnumSystemCodePage() it enumerates codepages from the cptables 
array. This array include all codepages. So when we use a symbol from Latin1, 
all bits are set (I've tested it long time ago, so maybe I'm mistaken, maybe 
1 bit or 2 are not set).
But only the following bits must be set:
FS_LATIN1 | FS_LATIN2 | FS_CYRILLIC | FS_GREEK | FS_TURKISH | FS_HEBREW | 
FS_ARABIC | FS_BALTIC | FS_VIETNAMESE | FS_THAI | FS_JISJAPAN | 
FS_CHINESESIMP | FS_WANSUNG | FS_CHINESETRAD

So, it's impossible to use EnumSystemCodePage()

If we use codepages from mlang_data[], everything works perfect.

The functions GetCPInfo/MultiByteToWideChar aren't also provide the list of 
needed codepages.

There is one extra problem:
I can't find the size of the dbcs_table->cp2uni array, so It needs to 
calculate it. This calculation works perfect, but maybe there is more easy 
way to obtain it?

[try 2] [2/2] mlang: Add implementation offnIMLangFontLink_GetCharCodePages

[Dmitry Timoshkov]

"Vitaly Perov"  wrote:
> This function must set only supported codepages bits
> The supported codepages are: 
> ttp://www.microsoft.com/globaldev/reference/WinCP.mspx

Again, it absolutely doesn't really matter what code pages Windows supports,
or MSDN declares as supported, the only thing that matters is what code pages
are valid for mlang APIs.
> For example, we use a symbol from Latin1 codepage.
> All codepages are include this symbol.
> So if we use EnumSystemCodePage() it enumerates codepages from the cptables 
> array. This array include all codepages. So when we use a symbol from Latin1, 
> all bits are set (I've tested it long time ago, so maybe I'm mistaken, maybe 
> 1 bit or 2 are not set).
> But only the following bits must be set:
> FS_LATIN1 | FS_LATIN2 | FS_CYRILLIC | FS_GREEK | FS_TURKISH | FS_HEBREW | 
> FS_ARABIC | FS_BALTIC | FS_VIETNAMESE | FS_THAI | FS_JISJAPAN | 
> FS_CHINESESIMP | FS_WANSUNG | FS_CHINESETRAD
>
> So, it's impossible to use EnumSystemCodePage()

It *is* possible to use EnumSystemCodePages.
> If we use codepages from mlang_data[], everything works perfect.

Although yes, using code pages from mlang_data is preferrable. So, you
can remove EnumSystemCodePages from the list of APIs to use.
> The functions GetCPInfo/MultiByteToWideChar aren't also provide the list of 
> needed codepages.

They do provide other information your implementation uses, like character
size and lead bytes (although you don't need that information, therefore
that APIs are not needed either).
> There is one extra problem:
> I can't find the size of the dbcs_table->cp2uni array, so It needs to 
> calculate it. This calculation works perfect, but maybe there is more easy 
> way to obtain it?

Forget about Wine internal code page structures. Try for instance implement
GetCharCodePages using only public Win32 APIs as an exercise.

To find whether a mapping for a unicode character exists in some code page
you could use WideCharToMultiByte(WC_NO_BEST_FIT_CHARS) for instance.