locked
Function TextOut() does not render Japanese characters either with the Calibri, or with the Arial fonts. Any explanation ? RRS feed

  • Question

  • It can be easily verified, by using the symbol dialog box in MS Word, that the Calibri font doesn't have the Unicode characters 0x062A and 0x660E. Nevertheless, the function TextOut() prints the character 0x062A (Arabic), but doesn't exhibit the character 0x660E (Japanese). What's the reason for this behavior ?

    From this page one can read : The Windows core fonts (Times New Roman, Courier New, Arial, Microsoft Sans Serif, and Tahoma) contain Latin, Hebrew, Arabic, Greek, and Cyrillic scripts but do not contain East Asian script characters. They link to fonts that do., which seems to contradict the result obtained in this program, if I replace the Calibri font by Arial, as the results will be the same, i.e., the Japanese character will be printed as invalid.

    LRESULT CALLBACK WndProc (HWND hwnd, UINT message, UINT wParam, LONG lParam)
    {
    	static HFONT s_hFont;	
    	
    	switch( message )
    	{
    		case WM_CREATE:
    		{
    			LOGFONT lf;
    			memset(&lf, 0, sizeof(LOGFONT));
    			lf.lfHeight = -MulDiv(20, 96, 72);
    			wcscpy_s(lf.lfFaceName, LF_FACESIZE, L"Calibri");
    
    			if( !(s_hFont = CreateFontIndirect(&lf)) ) return -1;
    		}
    		break;
    
    		case WM_PAINT:
    		{
    			PAINTSTRUCT ps;
    			BeginPaint(hwnd, &ps);
    			s_hFont = (HFONT)SelectObject(ps.hdc, s_hFont);
    			
    			wchar_t wchar1 = 0x062A;				//	Arabic character
    			TextOut(ps.hdc, 10, 10, &wchar1, 1);
    
    			wchar_t wchar2 = 0x660E;				//	Japanese character
    			TextOut(ps.hdc, 10, 50, &wchar2, 1);
    
    			s_hFont = (HFONT)SelectObject(ps.hdc, s_hFont);
    			EndPaint(hwnd, &ps);
    		}
    		break;
    		
    		
    		case WM_DESTROY:
    		DeleteObject(s_hFont);
    		PostQuitMessage(0);
    		break;
    		
    		default:
    		
    		return DefWindowProc(hwnd, message, wParam, lParam);
        }
        return 0L ;
    }

    Screen shot from the output


      
    • Edited by Wald B Friday, June 29, 2012 11:15 PM
    Friday, June 29, 2012 11:13 PM

All replies

  • That's not the point of my question. Your suggestion will create a font with Japanese characters, not a Calibri font. Once you set up the CharSet member, to a value different than ANSI_CHARSET = 0, the CharSet member will have higher priority than the font FaceName, when determining the font that will be returned by CreateFont(), ou CreateFontIndirect(). This can be verified by the FaceName member in the OUTLINETEXTMETRIC structure returned by the function GetOutlineTextMetric().
    Saturday, June 30, 2012 12:35 AM
  • To reinforce ColBackup's position, if you open the Windows utility Character Map, select Calibri and then use the "Go to Unicode" textbox to type 660E, you'll see that there are no Japanese characters.  If you change the font to Arial Unicode MS then you'll find the Japanese characters.

    Also note that you are using incorrectly the character types and function names.  The use of TextOut implies the use of TCHAR's.  Passing along any other character type is incorrect.  You just cannot rely on a project setting.  For example, some other person using a compiler could see your code as is and try it out in, say GCC.  They would have to know that they must #define UNICODE for your code to work.  Not good.  The best practice is to explicitly call the unicode function TextOutW.


    Jose R. MCP
    Code Samples


    • Edited by webJose Saturday, June 30, 2012 4:36 PM
    Saturday, June 30, 2012 4:33 PM
  • As I said before, this page contains the following sentence "The Windows core fonts (Times New Roman, Courier New, Arial, Microsoft Sans Serif, and Tahoma) contain Latin, Hebrew, Arabic, Greek, and Cyrillic scripts but do not contain East Asian script characters. They link to fonts that do."

    The underline is mine, to call attention to this point, which clearly says that those fonts should be able to render Japanese characters. But that's not what I found out. If I replace the font Calibri, by any one of those core fonts, the result is the same in my code, the Japanese character is rendered as an invalid character. Any explanation ?

    Saturday, June 30, 2012 4:43 PM
  • @webJose

    >> To reinforce ColBackup's position, if you open the Windows utility Character Map, select Calibri and then use the "Go to Unicode" textbox to type 660E, you'll see that there are no Japanese characters.  If you change the font to Arial Unicode MS then you'll find the Japanese characters. <<

    You don't have to reinforce this. This is exactly what I said on my first phrase in my first post, i.e., that the Calibri font doesn't have those two characters. Nevertheless, the code shows that you can print the Arabic character,  but not the Japanese. That's the point that I'm arguing here.

    >> Also note that you are using incorrectly the character types and function names.  The use of TextOut implies the use of TCHAR's.  Passing along any other character type is incorrect.  You just cannot rely on a project setting.  For example, some other person using a compiler could see your code as is and try it out in, say GCC.  They would have to know that they must #define UNICODE for your code to work.  Not good.  The best practice is to explicitly call the unicode function TextOutW. <<

    I doubt that any one would agree with this. But more important, please don't try to divert the attention to what is really being discussed here.  


    • Edited by Wald B Saturday, June 30, 2012 5:01 PM
    Saturday, June 30, 2012 4:54 PM
  • in my case, TextOut outputs both of those characters just fine if Calibri is specified for CreateFont, so I don't understand what the problem is
    maybe you need a code example?  if so, let me know

    Then show your code.
    Saturday, June 30, 2012 5:15 PM
  • I'm still getting an invalid character for the Unicode 0x660E
    Saturday, June 30, 2012 5:32 PM
  • If you check out the documentation of TextOut, what string type does it say you need to provide?  Is it the same as wchar_t* on all cases?  That's all I'll say about this.  You can take the advise or drop it.  Up to you.

    As for that article, I like it.  Looks nice.  I'll try to read it up entirely.  There's one thing that bothers me, though:  You say it says Arial is linking to some other font.  I believe you the article says that (I just haven't searched for the quote), but if that's true, then how come in my Windows 7 x64 PC I don't have a registry key value for Arial under HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink as per the article?  Would this be your case too?  Did you check your registry entries to ensure the linking was defined?  Does the article say of other sources of linking information?

    I also see a FontLinkControl DWORD value in the FontLink key.  I have it set to zero.  Could this be a master on/off switch for font linking?


    Jose R. MCP
    Code Samples

    Saturday, June 30, 2012 5:49 PM
  • The quality of the answers, at least on this thread, has deteriorated so much, as compared to what I used to see a few years ago. It's just unbelievable. 

    It's difficult for me to understand how you guys, Brian Muth, Wayne King, Viorel, Superman, Scott McPhillips, and others, whose opinions I used to respect, can live up to this.

    I'm giving up.

    Saturday, June 30, 2012 6:14 PM
  • The quality of the answers, at least on this thread, has deteriorated so much, as compared to what I used to see a few years ago. It's just unbelievable.

    It's difficult for me to understand how you guys, Brian Muth, Wayne King, Viorel, Superman, Scott McPhillips, and others, whose opinions I used to respect, can live up to this.

    I'm giving up.

    Well I find your attitude quite disrespectful.  If you don't find the answers helpful, just say "this doesn't help me because X or Y".  Do you need to make such a pejorative remark?  Let me remind YOU that YOU ARE IN NEED OF HELP.  Not us.  It is YOUR PROBLEM, not mine, yet I try my best to help you out.

    If you are going to just come here and insult everyone trying to help you, then just please stop coming.


    Jose R. MCP
    Code Samples

    Saturday, June 30, 2012 6:20 PM
  • The quality of the answers, at least on this thread, has deteriorated so much, as compared to what I used to see a few years ago. It's just unbelievable. 

    It's difficult for me to understand how you guys, Brian Muth, Wayne King, Viorel, Superman, Scott McPhillips, and others, whose opinions I used to respect, can live up to this.

    I'm giving up.

    @Wald B

    After reading the answers I have no other choice, but to agree with you.

    Saturday, June 30, 2012 8:42 PM
  • @webJose

    The important thing here is that the question has yet not been answered appropriately

    Saturday, June 30, 2012 10:26 PM
  • your code DOES display those characters

    if it doesn't display them on your system, seek the answer in your system's character set configurations

    what else is there to say?

    Saturday, June 30, 2012 10:34 PM
  • I didn't see anything that could be considered abusive in the OP's remarks. For me the question is still open, and by the way, it's a good question.
    Saturday, June 30, 2012 10:40 PM
  • I didn't see anything that could be considered abusive in the OP's remarks.


    Did I see anything that could be considered abusive in the OP's remarks?  It's as if you think I did.

    For me the question is still open, and by the way, it's a good question.

    To put it simply, his question was: "Why doesn't TextOut render the Han ideograph?"  It does.  Moreover, with the code he provided.  Isn't this the answer?

    Now, why his system doesn't display Han ideograph would be another question.  I tried to answer it too, by suggesting he checks his system's East Asian character set support, but instead, no response other than "deteriorated quality" comment has followed.

    I'm just a novice who asks questions here himself and was trying to help.  Am I qualified enough for OP's question answering needs?  Obviously not, so isn't webJose, a programmer with 20+ thousand points. 

    Saturday, June 30, 2012 11:49 PM
  • @ColdBackup

    Why did you suddenly erase three of your answers on this thread ? Whose instructions are you following ?

    Let me very clear with you. I have a Windows 7 x86 machine, with all the Japanese fonts available (MS Mincho, Meiryo, MingLiU, MS Gothic, Sumsun and Gulim). I challenge you to prove what you're saying, showing some code that prints the character 0x660E, or for that matter, that prints any Japanese character, using any one of the fonts Calibri, Times New Roman, Courier New, Arial, Microsoft Sans Serif or Tahoma, with a CharSet = ANSI_CHARSET.

    I also ask anybody that has a Windows 7 system, to copy and paste my code, to verify what I'm saying. It's as simple as that. It won't take you more than 5 minutes to do that. Thanks for your attention.

    Sunday, July 1, 2012 12:24 AM
  • I have a Windows 7 x86 machine, with all the Japanese fonts available (MS Mincho, Meiryo, MingLiU, MS Gothic, Sumsun and Gulim). I challenge you to prove what you're saying, showing some code that prints the character 0x660E, or for that matter, that prints any Japanese character, using any one of the fonts Calibri, Times New Roman, Courier New, Arial, Microsoft Sans Serif or Tahoma, with a CharSet = ANSI_CHARSET.

    it doesn't matter what charset your specify for CreateFont, it'll still display the characters with Calibri, I've tested it.  Calibri font is probably mapped by the font manager to a font that supports the characters specified, but you already knew that

    do you see the following  character? if so, can you copy and paste it in Notepad? does it look the same there?  if Notepad displays the character right, I don't know what else it can be, and regretfuly my bit of knowledge runs out here



    • Edited by ColdBackup Sunday, July 1, 2012 12:44 AM
    Sunday, July 1, 2012 12:43 AM
  • Why did you erase your three answers from this thread ? Whose instructions are you following ?

    Where is the code that confirms what you're saying ?


    Sunday, July 1, 2012 12:52 AM
  • I've got a Windows 7 system and I reproduced what Wald B said. The character U+660E shows with a .notdef glyph in my output. 
    Sunday, July 1, 2012 1:32 AM
  • Waid you are very sure of yourself, and yet you are unable to print the character.  I don't know Japanese, but I think my Win7 x64 PC prints it just fine.

    In a VC2010 CPP project I had lying around to try out something else, I included the following code in the window procedure:

    LRESULT CALLBACK WndProc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam){
    	static HFONT hFont;
    	switch (msg){
    	case WM_CREATE :{
    		LOGFONTW lf;
    		memset(&lf, 0, sizeof(lf));
    		lf.lfHeight = -MulDiv(20, 120, 72);
    		wcscpy_s(lf.lfFaceName, LF_FACESIZE, L"Calibri");
    		hFont = CreateFontIndirectW(&lf);
    	}
    
    		break;
    	case WM_PAINT:
    		{
    			PAINTSTRUCT ps;
    			HDC hdc = BeginPaint(hwnd, &ps);
    			hFont = reinterpret_cast<HFONT>(SelectObject(hdc, hFont));
    			WCHAR c1 = 0x062A;
    			WCHAR c2 = 0x660E;
    			TextOutW(hdc, 100, 100, &c1, 1);
    			TextOutW(hdc, 100, 140, &c2, 1);
    			LPWSTR szFontName = new (std::nothrow) WCHAR[128];
    			GetTextFaceW(hdc, 128, szFontName);
    			TextOutW(hdc, 100, 180, szFontName, wcslen(szFontName));
    			delete[] szFontName;
    			hFont = reinterpret_cast<HFONT>(SelectObject(hdc, hFont));
    			EndPaint(hwnd, &ps);
    		}
    ...
    }

    I get this:  https://skydrive.live.com/redir?resid=4B55847B2379AF30!734&authkey=!ALv0fcDM-aY-lnc

    So much for embedding the image.  There's a link.  Is that the Japanese character you are expecting?  Note that I did 120 dots per inch for font size.

    So there, that's basically your code.  It works in my PC.  So yes, ColdBackup is right:  It is YOUR PC.


    Jose R. MCP
    Code Samples





    • Edited by webJose Sunday, July 1, 2012 1:43 AM
    Sunday, July 1, 2012 1:34 AM
  • Using your code. That's what I've got :

    Sunday, July 1, 2012 1:50 AM
  • Since it works in some PC's and not in others, it is most likely a configuration issue.  I did my part and tried to help out that way but got told my response was inferior.  Same for ColdBackup's.  The OP in on his own as far as I'm concerned.

    BTW, Wald:  Look how nice of my code:  You can paste it in a project configured for ANSI build or UNICODE build and it just works.  When I copied yours I obviously had to change things around because my test project had to be setup to ANSI build due to the other thing I was testing.  But yes, you can dismiss that advice as you see fit.  Just have in mind that my code just works in other compilers as well, not just Visual Studio.


    Jose R. MCP
    Code Samples

    Sunday, July 1, 2012 2:03 AM
  • @Belloc

    Al least somebody confirms what I'm saying. Many thanks Belloc.

    @webJose

    This was said above by ColdBackup : "it doesn't matter what charset your specify for CreateFont, it'll still display the characters with Calibri, I've tested it.  Calibri font is probably mapped by the font manager to a font that supports the characters specified, but you already knew that

    do you see the following  character? if so, can you copy and paste it in Notepad? does it look the same there?  if Notepad displays the character right, I don't know what else it can be, and regretfuly my bit of knowledge runs out here".

    I'm carefully reproducing what he says, before he erases his answer. However the interesting part of this, is that, if you set

    lf.lfCharSet  = SHIFTJIS_CHARSET in your code, than I get the following output, which proves that my system is capable of printing the Japanese character. If the problem is one of configuration, as you say, then please tell how to correct my configuration !

    Sunday, July 1, 2012 2:38 AM
  • Figure it out yourself.  I'm through.  Good luck.

    Jose R. MCP
    Code Samples

    Sunday, July 1, 2012 2:53 AM
  • I think you're lying Jose. You didn't get that output with that code. 
    Sunday, July 1, 2012 3:02 AM
  • As if I care.  Think whatever makes you sleep at night.

    Jose R. MCP
    Code Samples

    Sunday, July 1, 2012 4:13 AM

  • I also ask anybody that has a Windows 7 system, to copy and paste my code, to verify what I'm saying. It's as simple as that. It won't take you more than 5 minutes to do that. Thanks for your attention.

    To somehow help you and the others, I did exactly what you asked on my very modest W7 Starter netbook Acer Aspire One. Your code renders Arabic and Japanese correctly - 

    In any case you don't need to be so harsh on people. You sure know that fonts' related issues have lots of not resolved (and even not answered) problems not only on Windows. There are not so many experts around that you can ask a question on this. For example, take a look at this blog and followed discussion from 2004.


    Sunday, July 1, 2012 11:13 AM
  • @Sergey Chepurin

    I repeat what I said above to webJose, if the apparent inconsistency is due to different "machine configurations", I ask you what should I do to correct those defects in my computer ?

    Sunday, July 1, 2012 12:24 PM

  • In any case you don't need to be so harsh on people. You sure know that fonts' related issues have lots of not resolved (and even not answered) problems not only on Windows. There are not so many experts around that you can ask a question on this. For example, take a look at this blog and followed discussion from 2004.


    @Sergey Chepurin

    I have copied this from the blog, you mentioned above :

    Raymond Chen 
    16 Jul 2004 3:01 PM
    #
    If you have Windows 2000 or better, my understanding is that GDI will do font linking automatically if your font is Tahoma, MS Sans Serif, a few select others. (I'm not the expert on this subject, so my answer to follow-up questions will likely be "I don't know.")

    which is exactly what I'm saying here from the very beginning of this thread.


    • Edited by Wald B Sunday, July 1, 2012 1:05 PM
    Sunday, July 1, 2012 12:36 PM
  • @Sergey Chepurin

    I repeat what I said above to webJose, if the apparent inconsistency is due to different "machine configurations", I ask you what should I do to correct those defects in my computer ?

    I have no idea. I also doubt that Microsoft's support specialists would be able to remotely advise you on this problem (especially, if the code in question works on other machines). I can only try to check it also on my Lenovo G550 notebook which has some different configuration and W7 Home Premium.
    Sunday, July 1, 2012 12:51 PM
  • In any case you don't need to be so harsh on people.

    @Sergey Chepurin

    Three answers from ColdBackup were very conveniently erased from the thread. Ask the forum admin to show you those posts, and you'll understand my remarks about the diminishing quality of the answers on this forum. And to my surprise, webJose reinforced ColdBackup's position, according to his own words shown above. 

    • Edited by Wald B Sunday, July 1, 2012 1:04 PM
    Sunday, July 1, 2012 1:00 PM
  • >Three answers from ColdBackup were very conveniently erased from the thread

    If there is an option to delete posts, people will use it from time to time. You don't have to be over suspicious on that matter.

    >And to my surprise, webJose reinforced ColdBackup's position

    webJose is, for sure, one of the experts on many C++ related subjects (don't know about internationalization) on this Forum. 

    But all this is out of topic.

    Sunday, July 1, 2012 1:25 PM
  • >Three answers from ColdBackup were very conveniently erased from the thread

    If there is an option to delete posts, people will use it from time to time. You don't have to be over suspicious on that matter.

    >And to my surprise, webJose reinforced ColdBackup's position

    webJose is, for sure, one of the experts on many C++ related subjects (don't know about internationalization) on this Forum. 

    But all this is out of topic.

    @Sergei Chepurin

    My post was considered abusive, and you say this is out of topic. Lol.

    But yourself, are you an expert on Windows internationalization ? It seems like I need an independent and an expert's opinion to close this matter, if that's all possible. It's difficult for anyone to receive "I have no idea" type answer, specially when we're talking about a computer, where everything, without a single exception, resumes to a 0 or a 1. No place for any value in between. 

    Sunday, July 1, 2012 1:45 PM
  • @Sergei Chepurin

    My post was considered abusive, and you say this is out of topic. Lol.

    But yourself, are you an expert on Windows internationalization ? It seems like I need an independent and an expert's opinion to close this matter, if that's all possible. It's difficult for anyone to receive "I have no idea" type answer, specially when we're talking about a computer, where everything, without a single exception, resumes to a 0 or a 1. No place for any value in between. 

    >My post was considered abusive, and you say this is out of topic. Lol.

    How is that related to the problem that "Function TextOut() does not render Japanese characters"?

    >But yourself, are you an expert on Windows internationalization ?

    I am by no means an expert in internationalization (and never said that). Actually, i don't believe there is one existing on this planet - could you imagine a person equally proficient in Thai (which has no space between words) and Hebrew or Arabic (right-to-left ones) and how to handle them on Windows or *NIX? I know something concerning Cyrillic and Hebrew languages implementation that is enough for a given purpose. You asked to check if your code renders Japanese correctly and i nicely confirmed that. 

    > It seems like I need an independent and an expert's opinion to close this matter.

    Some "matters" are difficult to close even having an "independent and an expert's opinion".


    Sunday, July 1, 2012 2:22 PM
  • How do I correct, or adjust, my computer configuration so that I can get Japanese characters printed according to MS standards ?
    • Edited by Wald B Sunday, July 1, 2012 2:30 PM typo
    Sunday, July 1, 2012 2:27 PM
  • Three answers from ColdBackup were very conveniently erased from the thread. Ask the forum admin to show you those posts, and you'll understand my remarks about the diminishing quality of the answers on this forum. And to my surprise, webJose reinforced ColdBackup's position, according to his own words shown above.


    What was in my replies that you considered "diminishing quality"?   A few lines of code based on CreateFont in order to get to the root of the problem faster by replacing unnecessary code paragraphs you've written?   Haven't you used my code sample to implement charset-selection capability and finally see the character you hadn't been able to see?   Since you stated its quality wasn't satisfactory, I've removed it so don't try to make a bad guy out of me now.
    • Edited by ColdBackup Sunday, July 1, 2012 3:12 PM
    Sunday, July 1, 2012 3:11 PM
  • How do I correct, or adjust, my computer configuration so that I can get Japanese characters printed according to MS standards ?

    Sunday, July 1, 2012 3:13 PM
  • I don't know for sure, but it seems like the Brazilian population with almost 200 million people is being discriminated by MS. From what I have gathered on other sites, this problem might be related to the locale established in my Windows 7 Home Edition, installed by Dell on my Vostro computer, which I bought two months ago. How is this possible ? I have a Professional Visual Studio 2010 and I can't make my program run as any other program in the world, because I live in Brazil !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    Taking into consideration this fact, I want to apologize to webJose when I said that he was lying, when he answered my question telling me that he was able to print the Japanese character in his program, something that I can't reproduce in my computer, and for that matter, in any Windows 7 Home Edition running in Brazil.

    Another important information : about 3 weeks ago I got in touch with MS in Brazil, and I told them that I was willing to upgrade to the Ultimate Windows 7 edition because of my interests in Internationalization. For my surprise, the MS employee answered on the chat line  that I would have to buy a new system, for this upgrade was not available in Brazil.

    This is really shameful from MS. I have been dedicating 12 years of my life studying and researching on MS software, and finally coming to the conclusion that I've been discriminated. And don't think I am any ignorant fellow from a third world country. I'm an engineer, with two masters degree, one of them from Stanford University. I know exactly what I'm talking about. 

     
    Monday, July 2, 2012 12:06 PM
  • I'm posting with some trepidation given the somewhat inflamed feelings expressed in this thread :-)

    I've discovered that indeed with Visual Studio 2012 RC, the Japanese character is being displayed. (I wonder if this is the version of VS that webJose is using.) When compiling with either Visual Studio 2008 or Visual Studio 2010 SP1, I'm seeing the behaviour as described by Wald B. I tested this on Windows 7 Home x64.

    Fonts and internationalization are far outside my area of expertise, but so I can't comment with much authority. It is noteworthy, however, that when programmer attempts to use a font with has missing glyphs, the operating system is free to substitute another font that has those missing glyphs when they are encountered. This is called a linked font. The operating system tracks these linked fonts under the registry key:

    HKEY_LOCAL_MACHINE–\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink

    On my system, I have the following under this registry key:

    Note that I don't have Calibri listed. However, if I manually add Calibri with a linked font MS Mincho, then I can see the output (using Wald B's code) using either Visual Studio 2008 or Visual Studio 2010:

    Hope this helps.

    I don't have an explanation why this is not required when compiling with Visual Studio 2012 RC.


    • Edited by Brian Muth Tuesday, July 3, 2012 1:15 AM
    Tuesday, July 3, 2012 12:59 AM
  • I have to add that on my Hebrew localized (plus installed English and Cyrillic locales) W7 Starter Acer Aspire One + VC++ 2010 SP1 Express the code in question compiles and outputs Arabic and Japanese correctly (just to clear any doubts about VC++ 2010).
    Tuesday, July 3, 2012 8:46 AM
  • @Brian Muth

    You can't refer to who I am, as I've changed my ID on this forum. But I can tell you, we have already exchanged fruitful and clever dialogues in the past here. I admire your sense of humor and professionalism, as well as of the other participants that I mentioned on a prior post. I'm really thankful for your reply.

    But this whole thing is becoming more and more confusing. First of all, the conviction that I'm being discriminated in Brazil, comes from this unique answer I got on Stackoverflow and from this page where you'll find this (I introduced the characters in bold to highlight my point) :

    "The change depends on the setting of the NLS default system locale (meaning of course that this is a setting that is not just for non-Unicode programs!). It affects the behavior of several things, according to the rules spelled out above for each group -- linking to the fonts in that given order:

    • The preferred font for each group (for EA system locales)
    • Lucida Sans Unicode
    • Microsoft Sans Serif (not MS Sans Serif!)
    • Tahoma"

    Now, referring to one of the points you mentioned : 

    >> Note that I don't have Calibri listed. However, if I manually add Calibri with a linked font MS Mincho, then I can see the output (using Wald B's code) using either Visual Studio 2008 or Visual Studio 2010: <<

    But how do you explain that the Arabic character is rendered normally with Calibri, without any linking for this font on your machine. That's the same on my computer. Also, bear with me, I have a registry key that links Tahoma to MS Gothic, MS UI Gothic, MingLiU, PMingLiU, etc ... and all these fonts have the Japanese character 0x660E, but I can't have the character printed, even when I replace Calibri by Tahoma in my code. How come ????

    On this page, you can read this "If font linking is enabled on your device, you can examine the registry by enumerating the subkeys of the registry key at HKEY_LOCAL_MACHINE–\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink to determine the mappings of linked fonts to base fonts.". I wonder if font linking is enabled, or not, on my machine ????

    Nevertheless thanks a lot for your answer. I still believe something useful will come out of this thread.



    • Edited by Wald B Tuesday, July 3, 2012 1:21 PM typo
    Tuesday, July 3, 2012 12:59 PM