From: andrew on
Hey thanks, the overriding of the edit menu messages works. And when pasted
into Word shows Khmer.

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:ipt0i5h8djbdt3dhe68vln8q8ugeg28cco(a)4ax.com...
> See below...
> On Wed, 9 Dec 2009 22:10:39 -0500, "andrew" <thegroup(a)microsoft.com>
> wrote:
>
>>I took a look at the first link you suggested. You are right it does not
>>apply. All .RC references use the Unicode version of the control. I also
>>tried the program in the second link - a nifty littl tool. For me the
>>Khmer
>>page showed Red squares - "no fallback".
>>
>>The Khmer fonts that I have were downloaded from a site the promotes
>>Khmer.
>>I have :
>>Khmer OS (True Type)
>>Khmer OS Fasthand (True Type)
>>Khmer OS Freehand (True Type)
>>Khmer OS Muol (True Type)
>>Khmer OS System (True Type)
>>Khmer OT (True Type)
>>Limon S1 (True Type)
>>
>>The problem could very well be a font issue since these did not come from
>>Microsoft - I am running Windows XP.
>>
>>After calling SetFont, and even before, the RichEdit showed what looked
>>like
>>thick pipe ('|') characters for all Khmer characters. I am sorry but I
>>cannot get Copy to work from my RichEdit. This may be another problem
>>that
>>may just be a style setting. However I do save the text in the control
>>(via
>>GetWindowText into a Unicode buffer) to a Unicode text file. What appears
>>as pipes in the RichEdit actually is saved correctly and displays as Khmer
>>in Word. So the Unicode data is preserved by the control but just not
>>displayed properly.
> ****
> I found that I had to provide my own right-click menu item, and send the
> WM_COPY message
> to the rich edit control myself. In addition, if you are using the Edit
> menu item, you
> usually have to handle the ID_EDIT_COPY message (and its update) in the
> view that holds
> the rich edit, and the command message has to send a WM_COPY message to
> the edit control
> itself. Usually, although the control may not display the characters
> properly, if you
> copy and then paste into a Unicode-based app, you will get the correct
> Unicode values in
> the paste.
>
> For the update handlers, I usually implement something that first
> determines if the
> control with the focus is an edit control (regular EDIT, Rich Edit, etc.)
> and then add the
> following code:
> check for CF_TEXT and/or CF_UNICODETEXT and only enable Paste
> if something valid is found (for rich edit, you might want to allow
> pasting images
> so that takes some additional checking)
>
> For a rich edit, you can EnumClipboardFormats and use the EM_CANPASTE
> message to determine if any of them are pastable; if any one is, then you
> enable Paste
>
> If the control is marked ReadOnly, do not enable Cut or Paste
>
> If the selection is empty, do not enable Cut or Copy
>
> It gets a little tricky if your rich edit control has protected fields
> within
> a highlighted region, and I punted that problem the last time I
> used them by simply disallowing copy, cut or paste if the highlighted
> area overlapped a protected region
> joe
> *****
>>
>>Thank you for your suggestions. I had no idea that there was something
>>like
>>"font fallback magic". This is something to think about. I have asked to
>>have Windows 7 installed on a machine. When this is done I will try the
>>program on it. If it works we will just have to say that full Khmer
>>support
>>comes only when the program runs under Windows 7.
>>
>>Thanks again.
>>
>>
>>"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message
>>news:Xns9CDBE38CAC5DCMihaiN(a)207.46.248.16...
>>>> I have a CRichEditCtrl in a Unicode application that will not display
>>>> Khmer
>>>> when I use SetWindowText but will display it when the same text is
>>>> pasted
>>>> from a Word document.
>>>
>>> Sounds like this:
>>> http://www.mihai-nita.net/article.php?artID=20050709b
>>>
>>>> Many other languages (e.g. Japanese, Chinese, French,
>>>> Arabic) will display properly with either method of getting the text to
>>>> the
>>>> control.
>>>
>>> But this part is weird. The explanation above would not allow for
>>> Chinese/Japanese/Arabic.
>>> So my second guess: bad font.
>>> Chinese, Japanese, Arabic (and others) are "fixed" by font fallback
>>> magic.
>>> Khmer might not be the case (depends on the Windows version, Win 7 is
>>> ok).
>>>
>>> You can use this http://www.mihai-nita.net/article.php?artID=charmapex
>>> to
>>> jump (Ctrl+J) to the Khmer block and see if you get characters in black
>>> (the font has the char), red (font fallback) or squares (missing glyph,
>>> no fallback).
>>>
>>> Windows 7 is the first one officially supporting Khmer
>>> ("official" means font, font fallback, keyboard, locale information).
>>>
>>>
>>>> and used CWnd::SetFont for the RichEdit before calling
>>>> SetWindowText. This did not work.
>>>
>>> If you set the font it should work.
>>> What was the result? Squares? Question marks? Junk?
>>>
>>>
>>>> Having this one language fail seems to be odd because I did nothing
>>>> special
>>>> to make the others work.
>>>
>>> The font linking/substitution/fallback/magic done by the OS is not equal
>>> for
>>> all languages. And it can only happen to system fonts.
>>> If you install a "Khmer OS System" that is not used by the OS for
>>> fallback.
>>>
>>>
>>>> Therefore there is not much more I can offer about
>>>> what I am doing or not doing.
>>>
>>> What was the result when you set the font? Squares? Question marks?
>>> Junk?
>>> If you select the text in the RichEdit control and paste it in Notepad,
>>> and/or Word (direct, and paste special - plain text), and set the font
>>> to "Khmer OS System", does it look ok?
>>>
>>>
>>>
>>> --
>>> Mihai Nita [Microsoft MVP, Visual C++]
>>> http://www.mihai-nita.net
>>> ------------------------------------------
>>> Replace _year_ with _ to get the real email
>>>
>>
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


From: andrew on
There is a lot of good information in those blog entries - still reading. I
might have been a little cavalier with my use and expectations of Unicode
since the system has been working well with many languages. I'll see what
the Windows 7 machine does.

Thank you for the information.
A.B.

"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in message
news:Xns9CDCE47356D80MihaiN(a)207.46.248.16...
>
> Between this:
>
>> After calling SetFont, and even before, the RichEdit showed what looked
>> like thick pipe ('|') characters for all Khmer characters.
>
>
> And this:
>
>> However I do save the text in the control (via
>> GetWindowText into a Unicode buffer) to a Unicode text file. What
>> appears
>> as pipes in the RichEdit actually is saved correctly and displays as
>> Khmer
>> in Word. So the Unicode data is preserved by the control but just not
>> displayed properly.
>
> I am pretty sure the font is not set properly.
>
>> Thank you for your suggestions. I had no idea that there was something
>> like "font fallback magic". This is something to think about.
>
> Sure, the real name is not "font fallback magic" :-)
> Windows tries hard to select a font that can display the text.
> But there is no such thing as "Windows", there are various parts
> working separately, sometimes they conflict a bit.
> Each part has it's own mechanism and sometimes with a different name.
> There are logical fonts, and font mapping, and font substitution,
> and font linking, and font fallback.
> Some stuff hapen in GDI, some in Uniscribe, some by MLAng, some in the
> RichEdit control, Word add it's own smarts.
> So it is tough to say who is doing what if all you see is the final
> result.
>
> Here are some great blog entries:
>
> What about logical fonts? (with tons of other links from there)
> http://blogs.msdn.com/michkap/archive/2006/03/18/554308.aspx
> Font Linking vs. Font Fallback
> http://blogs.msdn.com/michkap/archive/2005/10/01/476022.aspx
> Font substitution and linking #1
> http://blogs.msdn.com/michkap/archive/2005/03/20/399322.aspx
> http://blogs.msdn.com/michkap/archive/2005/05/16/417711.aspx
> About Khmer:
> http://blogs.msdn.com/michkap/archive/2008/12/03/9168086.aspx
>
> But overall things "just work" and they got better and better from
> a version of Windows to the next one.
> But for Khmer, Win7 is definitely the first one where it is officialy
> supported. Might (kind of) work with older versions, but no promises.
>
>
> --
> Mihai Nita [Microsoft MVP, Visual C++]
> http://www.mihai-nita.net
> ------------------------------------------
> Replace _year_ with _ to get the real email
>