Why DrawTextA corrupts chinese text?

[Chris Becke]

We had a problem with DrawTextA corrupting chinese text.

Inside our Dialogs WM_PAINT handler we were getting text from the
applications string table and drawing it :-

char szBuffer[256];
LoadString(hResrc,IDS_MESSAGE,&szbuffer,sizeof (szBuffer));
DrawTextA(hDC,szbuffer,-1,&rcText,DT_SINGLELING);

No problem at all. At least on most systems we tried it on. Until our
chinese translators said the string was garbage on our simplified chinese
localization. Windows XP specifically. Our Windows 2000 and 98 testers
hadn't reported problems...

So I got hold of a simplified chinese XP box, traced through the code, and
examined the contents of szBuffer, and found that it contained the expected
byte sequence for the 936 codepage. The LoadString *had* used the correct
codepage to convert the string to ansi from unicode.

The DrawText however is displaying garbage characters. Not blocks, or ??'s,
but random looking 'chinese'ish characters (to my untrained western eyes)

On a hunch, I took the 936 byte sequence, and did a
MultiBytetoWideChar(950,... conversion. 950 being the "traditional chinese"
codepage. And it produced in the debug window the exact text the DrawText
was producing.

So, LoadString is using the system code page.
DrawText was using codepage 950 to render the string! Why would it do this?
GetACP, GetThreadLocale etc *all* indicated a simplified, not traditional,
chinese localized system. The ansi APIs in a system should all be using the
same ansi code-page right?

Wait. The problem was traced to our font creation. When creating the font we
had inadverdently specified the CHINESEBIG5_CHARSET, rather than the
GB2312_CHARSET character set.

However - the parameters to CreateFont are meant to be hints to the font
mapper: I can understand the incorrect font definition causing a font
without symbol support being loaded. i.e. I'd expect the undisplayable
character glyph to be used, perhaps even ??'s.

I would't expect DrawTextA to use a different code page. The ability of
DrawTextA to use codepages other than the system ansi code page certainly
isnt mentioned *anywhere* in MSDN or in the MS KB.

[Tim Roberts]

"Chris Becke" <chris...@gmail.com> wrote:
>
>Wait. The problem was traced to our font creation. When creating the font we
>had inadverdently specified the CHINESEBIG5_CHARSET, rather than the
>GB2312_CHARSET character set.
>
>However - the parameters to CreateFont are meant to be hints to the font
>mapper: I can understand the incorrect font definition causing a font
>without symbol support being loaded. i.e. I'd expect the undisplayable
>character glyph to be used, perhaps even ??'s.

If you read the web pages that describe the Windows font mapper, you'll
find that character set is THE most important criteria that it uses.

>I would't expect DrawTextA to use a different code page.

It's not all that surprising, is it? The character set tells the system
how to map the 8-bit characters you draw into the Unicode code points in
the font. In this case, you are lying to the system. The resources are
being converted from Unicode to 8-bit using the system code page, but those
8-bit strings aren't actually IN that character set.

>The ability of
>DrawTextA to use codepages other than the system ansi code page certainly
>isnt mentioned *anywhere* in MSDN or in the MS KB.

Well, why don't you just use DrawTextW? That way, you avoid the character
set confusion altogether. The resources are stored in Unicode to begin
with. Just keep them that way.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[Michael (michka) Kaplan [MS]]

All true.

And my 2 cents on it here:

http://blogs.msdn.com/michkap/archive/2006/08/22/707665.aspx

:-)

--
MichKa [Microsoft]
NLS Collation/Locale/Keyboard Technical Lead
Globalization Infrastructure, Fonts, and Tools
Blog: http://blogs.msdn.com/michkap

This posting is provided "AS IS" with
no warranties, and confers no rights.

"Tim Roberts" <ti...@probo.com> wrote in message
news:4h9le2ddn8vou1pjq...@4ax.com...