Click here to Skip to main content
15,215,865 members
Rate this:
Please Sign up or sign in to vote.
See more:
After more research and writing a couple of demo apps in both C++ and C#, I am revising this question to better target the issue that I have been seeing.

Problem statement: I have a (Visual Studio) MFC Unicode app that is used by some people in Japan. One of the app's functions outputs an enhanced metafile to the clipboard for pasting into other applications. The MFC app is an OLE server app and uses COleServerItem::CopyToClipboard to add the metafile to the clipboard. Some of the text in the metafile use glyphs with character codes > 127. On a Japanese version of Windows (with a en-US language pack installed), those glyphs do not render properly when pasted into another application. Instead of the expected symbols, they are rendered as some latin chars in some other font. Doesn't make any difference what font is used.

The following is what a demonstration MFC app draws to the screen using special characters from the Symbol font:[^]

When copying and pasting the above enhanced metafile into WordPad on a Japanese version of windows, the result is:[^]

If I change the strings that use the glyphs from CString(wchar_t) to CStringA (char), and use TextOutA instead of the Unicode verison, then the glyphs do render properly!

An additional workaround, instead of using COleServerItem::CopyToClipboard, is to "manually" put data on the clipboard using standard C++ clipboard functions like OpenClipboard, EmptyClipboard, SetClipboardData, CloseClipboard. This also fixes the problem without having to change the strings in the metafile to ANSI. So one might think that the problem is in COleServerItem::CopyToClipboard.

However, there is a related problem that doesn't involve the clipboard. The app uses a legacy MSFlexGrid OCX. The com object uses OLE which is Unicode, but on a Japanes Windows system, when the grids are displayed on screen, the special glyphs (extended ascii char codes > 127) also render improperly.

Note that if one just copies and pastes plain text in whatever font, then there isn't a problem.

I have created a Git repository with a Visual Studio MFC solution that demonstrates the problem at GitHub - brewerpm/JapaneseWinClipboardUnicodeProblem: VS MFC solution to demonstrate using extended ASCII chars with clipboard and OLE on Japanese version of Windows[^] .

Other things I have tried (1) Adding a CF_LOCALE record to the clipboard that specifies "en-US"; (2) specifying the locale as "en-US" using _wsetlocale(LC_ALL, L"en-US") at the beginning of the program (InitInstance) and (3) setting the codepage to Western 1252.


What I have tried:

(1) Adding a CF_LOCALE record to the clipboard that specifies "en-US"; (2) specifying the locale as "en-US" using _wsetlocale(LC_ALL, L"en-US") at the beginning of the program (InitInstance) and (3) setting the codepage to Western 1252.
Updated 15-Apr-20 6:48am
phil.o 27-Mar-20 20:06pm
Interesting question :)
Concerning Wordpad with the clipboard, the clipboard only holds the bytes representing the string in the codepage of the application. It does not carry any font information; thus, on pasting, Wordpad displays copied text with its own configured font. I don't think you can get around that (apart from manually changing the font for concerned characters, but I'm pretty sure this is not acceptable for you).
I can't provide an answer for the rest, unfortunately; I'm deeply interested in possible solutions, though.
RockyMu 28-Mar-20 9:59am
Thanks for your response. Actually, WordPad does retain font info and pasting from the clipboard with special font glyphs works fine (in Western Windows versions). Maybe WordPad was a bad example, which I only used because it's what is available on the Japanese Windows VM I created for testing. The main point is that copy and paste produces the wrong font in Japanese (probably all east Asian) versions of Windows.
KarstenK 15-Apr-20 13:44pm
My best tip is that you must encode these speific chars with some unicode escape code yourself and copy plain text. (somehow like HTML)
RockyMu 15-Apr-20 17:11pm
Thanks, Karsten. I think just encoding them as ANSI is the easiest workaround. Unicode is supposed to solve all these types of problems. That's what has me puzzled.
RockyMu 16-Apr-20 7:55am
This problem is currently in triage at Microsoft Developer Community

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100