Font substitution problem
Maël Hörz
It seems that Windows automatically chooses another font when the
selected font does not contain the needed character.
This is fine with me, except that it doesn't seem to work consistently.
I.e. Chinese characters are printed but Korean ones aren't, except if
the string that should be printed also contains Chinese characters.
See this example code snippet (the font in the device context is
"Courier New, 10pt":
{
wchar_t c = 0xC758; // Korean character
wchar_t c2 = 0x800C; // Chinese character
wchar_t s[1] = {c};
wchar_t s2[1] = {c2};
wchar_t s3[2] = {c,c2};
wchar_t s4[2] = {c2,c};
// Single Korean character produces empty box <== problem
ExtTextOutW(dc, 0, 0, 0, NULL, s, 1, NULL);
// Single Chinese character prints correctly
ExtTextOutW(dc, 0, 20, 0, NULL, s2, 1, NULL);
// Combined Chinese and Korean characters print correctly
ExtTextOutW(dc, 0, 40, 0, NULL, s3, 2, NULL);
// Combined Chinese and Korean characters print correctly
ExtTextOutW(dc, 0, 60, 0, NULL, s4, 2, NULL);
}
My explanation of this that apparently Windows automatically chooses a
substitution font when it detects Chinese and therefore prints Chinese
characters correctly. For whatever reason it doesn't do this for Korean.
However if the string that should be printed contains a Chinese
character the system seems to switch to this "Chinese"-font which
happens to also include Korean characters.
Is there a way that I can either:
(1) force Windows to always fail (i.e. draw an empty box) when a
character is not part of the font selected in the device context
or
(2) force it to consistently substitute the selected font with a font
that contains the character to be printed?
Regards, Maël.
Michael S. Kaplan [MSFT]
You could of course pick a font that is actually IN the font link chain
(e.g. Lucida Console) to see if it helps....
--
MichKa [Microsoft]
Fundamentals Technical Lead
Windows International
Blog: http://blogs.msdn.com/michkap
This posting is provided "AS IS" with
no warranties, and confers no rights.
"Maël Hörz" <no...@none.invalid> wrote in message
news:uZwjz1zP...@TK2MSFTNGP02.phx.gbl...
Maël Hörz
and I have the East-Asian languages files installed.
> You could of course pick a font that is actually IN the font link chain
> (e.g. Lucida Console) to see if it helps....
Lucida Console instead of Courier New gives the same results.
What do you mean by font link chain and how do I know if a font is part
of it?
Thanks, Maël.
Mihai N.
> selected font does not contain the needed character.
What lfCharSet are you using when you create the font to select in the HDC?
You should use DEFAULT_CHARSET
(See the "DEFAULT_CHARSET in LOGFONT" section in
http://www.microsoft.com/globaldev/getwr/steps/wrg_font.mspx)
--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
Maël Hörz
>> It seems that Windows automatically chooses another font when the
>> selected font does not contain the needed character.
>
> What lfCharSet are you using when you create the font to select in the HDC?
> You should use DEFAULT_CHARSET
ANSI_CHARSET, CHINESEBIG5_CHARSET or GB2312_CHARSET result all in the
same problem.
Mihai N.
> ANSI_CHARSET, CHINESEBIG5_CHARSET or GB2312_CHARSET result all in the
> same problem.
Weird. I can reproduce the problem.
And even more interesting, DrawText works (in exactly the same conditions)
Maël Hörz
> And even more interesting, DrawText works (in exactly the same conditions)
Thanks.
Is my assumption correct that font linking/substitution is only done on
Windows 2000 and up, but not on NT or Win9x?
One problem that is left is that most (maybe all) functions in GDI seem
to be affected by this issue. GetCharABCWidths also does not return the
expected results, and I don't think I can replace that with DrawText,
while I can use DrawText instead of GetTextExtentPoint32 and ExtTextOut.
If anyone has an idea what setting might be the cause for this strange
problem, don't be shy and tell me :-)
My line of thought was:
There might be something similar to the API SetMapperFlags that
influences font substitution, directly or indirectly. My guess is that
there might be a setting that affects GDI but not DrawText since it is
in user32.dll.
Regards, Maël.
Mihai N.
> Windows 2000 and up, but not on NT or Win9x?
And it is getting better. The one in XP is better than the one in 2000,
and Vista does better than XP.
In a version or two it will be impossible to show squares anymore :-)
> One problem that is left is that most (maybe all) functions in GDI seem
...
> there might be a setting that affects GDI but not DrawText since it is
> in user32.dll.
More details on what you are trying solve might help.
If you have to support Win 2000 (and maybe 9x), then the only real option
is to select a font that you know it supports the text you want.
Maël Hörz
> If you have to support Win 2000 (and maybe 9x), then the only real option
> is to select a font that you know it supports the text you want.
font substitution on versions below 2000, I can only do some special
handling for Windows 2000+.
What I am doing is maintain a code editor component. So I have to
manually print characters on the screen, therefore this inconsistent
behaviour is a problem. Also I cannot force the user to use a special font.
I thought that maybe uniscribe hasn't this error, until now I shyed away
from using it because it seems more complex.
Mihai N.
> font substitution on versions below 2000, I can only do some special
> handling for Windows 2000+.
>
> What I am doing is maintain a code editor component. So I have to
> manually print characters on the screen, therefore this inconsistent
> behaviour is a problem. Also I cannot force the user to use a special font.
>
> I thought that maybe uniscribe hasn't this error, until now I shyed away
> from using it because it seems more complex.
If you have to run in such old systems, I am afraid uniscribe is your
only chance. But you have to check if it is legally ok to redistribute.
Check the license.
Option 2, easyer maybe, is to try and relax some of the requirements.
Either give up Win 9x, or force a certain font (if the font does not
have the glyphs, it is pointless anyway).
It is possible that the Win 95 requirement "comes from above," but
you can try to speak the money language: how much do we really
make from win 95 to be worth the ammount of work we do?
Maël Hörz
> only chance. But you have to check if it is legally ok to redistribute.
> Check the license.
are displayed as boxes (that is okay), but there I didn't see the
problem "Korean character doesn't show on its own but when together with
Chinese character it does show". That is why I asked if font linking is
done in Windows9x/NT. Since it is not I can leave the code as is for
Win9X/NT and use ExTextOut etc. (the code for the edit control is
already implemented, it is just about fixing the issue under Win2000+).
> If you have to run in such old systems, I am afraid uniscribe is your
> only chance.
I guess you meant "new systems", since Windows 2000 and higher are the
Windows versions which cause "the sometimes a Korean character is
visible sometimes not"-issue.
Anyway, I'll try uniscribe.
Thanks again,
Maël.