by Michael S. Kaplan, published on 2007/06/05 11:42 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/06/05/3098947.aspx
Have you ever played volleyball?
I have, in a past life (back when I was able to stand upright!). and I was most struck by the pattern of using three hits -- receive it, setting it up, and spiking it.
I was not a professional player or anything, and obviously not all the terms are right (the actual terms are more like the bump, set, and spike). But the descriptions should be comprehensible and I am trying to frame things here....
I am going to try that pattern for a moment here. I already don't think it will work terribly well, but it won't hurt to give it a try, I figure.
First, the the receiving -- easy enough, I get questions all the time. This one comes from Dansk and was asked first in the microsoft.public.vc.mfc newsgroup and then in the microsoft.public.win32.programmer.international newsgroup:
Hi all,
You might be interested (and even give more info) about a discussion I had on microsoft.public.vc.mfc, thread named "CListCtrl unicode doesn't display korean characters correctly"
I had a problem with an MFC unicode-compiled application.
Description of the problem:
- The application is a dialog box vith a CListCtrl and a CEdit
- The application has to display strings in various languages in the CListCtrl.
- Once the user selects an entry ni the CListCtrl, the string is also displayed in the CEdit
- Both CEdit and CListCtrl have their default font changed to "Arial Unicode MS"
- The CListCtrl is owner data and the data is in a memory structure (a list of strings).
- Strings are correctly displayed in many languages (chinese, japanese, thai, english, greek, russian, ...) *except* in korean. In that case, I just get squares instead of characters.
- when I select an entry in the list, the string is *correctly* displayed in the CEdit (ie no squares, just korean characters)
- when the string is too long to be displayed in the CListCtrl, the tooltip displayed by the control has corect characters (not the same squares displayed below it)
Workaround:
Thanks to MrAsm, I could solve the problem.
The workaround is to prefix *every* string with a BOM (0xFF, 0xFE)
So, the question is : "Why?"
Why the ListCtrl needs the BOM, why the Edit does not, and why korean?
Thank you
Dansk
Environnement:
Windows XpSp2 pro - French - IE7 - VC6 (all service packs)
Now there are a lot of things that could be said about Arial Unicode MS. some of them might even be positive, and when you get down to it Microsoft paid Agfa Monotype a buttload of money to have this huge font designed to cover so many characters.
Though to be perfectly honest, there is very little you can say about it that is good when you are talking about support for some languages, such as Korean, for instance.
Even without the particular problem being reported here.
And even not specific to anything other than the conflict between the font's design and important typographic principles in other languages.
So anyway, if you are in the newsgroups or if you look now and see the thread, you should say nothing (since solutions were discussed and we are not there yet), but....
Does anyone have any thoughts about this they'd like to suggest? Beyond the vague sense that Arial Unicode MS is particularly ill-suited to this task (though the above is my subtle attempt at a volleyball "bump" or hint or whatever).
Next I'll post the "set" that gets into what is going on here, along with maybe another fun example of the problem....
This post brought to you by ᄀ (U+1100, a.k.a. HANGUL CHOSEONG KIYEOK)
# Maurits [MSFT] on 6 Jun 2007 12:01 PM:
Technical terms: "dig", set, spike (can ya dig it?)
# Mihai on 6 Jun 2007 12:29 PM:
When text in several scripts is displayed at the same time (and in the same control), switching the fonts for each language might not be possible (or might even look ugly).
The "one font fits all" solution is not really a good solution (you cannot really use the same font for Japanese/Chinese Simplified/Chinese Traditional).
On the other side, Arial Unicode MS seems to be designed for this kind of scenario, and there is a need to support such scenarios.
Idea 1.
But in this case we are talking about Korean, and the code points used for Korean are not shared with other scripts (like the code points in the CKJ Unified Ideographs block).
So there is no real excuse for the Korean in Arial Unicode MS to not respect the proper Korean look.
Idea 2.
As a programmer I hate when I ask for something, it is technically possible, but someone decides that they know better.
In this case I ask for Arial Unicode MS, it contains the proper Korean glyphs, but I get squares.
Idea 3.
OpenType fonts have the possibility to store language-specific glyphs, so this might be a way to use the same font for Chinese Simplified/Traditional (for instance), but this would mean that each item in the list should be tagged with a language ID. Not easy.
Idea 4.
The support for languages gets better and better, it is more and more common to see applications in one language running on OS with UI in second language and processing data in a third language (or multilingual content).
This opened some new cans of worms:
- the UI font ("MS Shell Dlg" and "MS Shell Dlg2" fail to solve the problem)
- the common controls, common dialogs, and the buttons for MessageBox
- MUI API for incomplete 3rt party applications
Ok, I don't think this matches the request:
"Does anyone have any thoughts about this they'd like to suggest?"
because there is nothing I suggest (yet :-) That part needs some more thinking.
But these are some thoughts :-)
referenced by