3

Under windows CE 6, I use AddFontResource() to load arialuni.ttf (Arial Unicode MS, version 1.0.1) into the system font list, and all our supported far east languages (Japanese, Korean, Simplified, and Traditional Chinese) appear correctly when the text draws to the screen using the font.

The same technique does not produce far east characters on the screen under Windows Compact 7. I get empty boxes instead of the actual characters appearing on the screen, something I've seen when the font doesn't support the necessary character set.

I'm using the same code for both platforms, and the same font file. I've debugged through the code to verify that a) The OS claims that the font is actually loaded into the system fonts list via AddFontResource(), b) The OS claims that the font loads into the screen device context before actually drawing the text, and c) The actual far east characters are in the buffer I hand off to DrawText(). This is exactly the same thing that works under CE6.

What's odd is that our supported eastern-European languages (Russian, Czech, Bulgarian) appear correctly on Windows Compact 7 whether or not I load arialuni.ttf. The registry says that the default system font is Tahoma, but I didn't think Tahoma supports anything other than basic western-European languages. It doesn't under CE6.

I would rather not add or use other fonts. Arialuni.ttf supports pretty much every language we're likely to support, and it's already the one and only one we use for non-western-European languages.

There are already several other true-type fonts installed, so that option (and not raster fonts) is already in our OS build.

  1. Is this arialuni.ttf compatible with Windows Compact 7?
  2. Is there something you have to build into the OS image to add support for far east languages to make this type of font loading and text drawing work?
  3. Am I wrong about Tahoma and it's now supporting eastern-European languages?
  4. What am I missing?

Thanks for any and all ideas.

James Barnard
  • 266
  • 2
  • 5
  • What are you using to build your app? What programming language are you using? What are you running your app on? I know Windows CE uses Unicode by default. Is it possible you need to define UNICODE in your project for Windows Compact 7? – Jim Rhodes May 03 '16 at 19:12
  • We've been using Visual Studio 2008 for years with success on CE 6 and continue to use it successfully with Compact 7. While we have some C# components, the one in question is a C++ executable. We have always built with Unicode support in order to pick up non-western-European foreign language support such as Russian, Bulgarian, Czech, Japanese, Korean, and Chinese (traditional and simplified). As I stated above, only the far-eastern languages do not draw correctly, and I don't understand why. – James Barnard May 04 '16 at 12:08

1 Answers1

2

  1. This version of arialuni.ttf is indeed compatible with Windows Compact 7.

  2. Unclear. Something about the OS images allowed font mapper under CE6 to map our requests correctly, but not under CE7.

  3. No. The default tahoma.ttf built into CE7 does support eastern-European character sets but not far-East character sets.

  4. Our program calls CreateFontIndirect() to obtain a handle to a GDI font resource that we can select into the screen's device context when drawing text to the screen. This call uses a LOGFONT structure that we populate with the attributes of a font we want, and behind the scenes, the system's font mapper component looks through the fonts of which it's aware and returns the one that it thinks is the best match.

    Initially, we only specified the character height, weight, and the font family name. By default, the character set requested was ANSI_CHARSET (0). This always returned us a reference to the arialuni.ttf font on our CE6 platform. On our CE7 platform, though, font mapper mapped the request to the tahoma.ttf file.

    I modified the LOGFONT structure content to include asking for the Japanese character set (LOGFONT.lfCharSet = SHIFTJIS_CHARSET). On both platforms, only the arialuni.ttf font file supports this language, so both font mappers now always return us a reference to the desired font.

    This change works on both CE6 and CE7 platforms. Western-European, eastern-European, and far-East languages all draw correctly now because arialuni.ttf supports all of these character sets, and more.

It's unclear why the CE6 platform mapped the font correctly while the CE7 platform did not. We control the fonts built into our devices, so we can guarantee the uniqueness of Japanese character support to just arialuni.ttf. This is apparently sufficient to get the font mapper to do what we want.

James Barnard
  • 266
  • 2
  • 5
  • Doesn't MS Mincho support Japanese? And it was present in CE6, though i am not sure about CE7... I had some similar problems of text being displayed wierdly, though it was while writing to file, the UI displayed properly (it was a Japanese UI). I was advised to convert the text before writing, something like this: //For Shift-JIS // cData is the text data to be written to file. CStringA outputString = CW2A(cData, 932); cFile.Write(outputString, ::strlen(outputString)); How about trying a reverse of this? – PRinCEKtd May 30 '16 at 07:26