Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Libraries and TheIDE: i18n, Unicode and Internationalization » It's suspected to be an issue with Font.
Re: It's suspected to be an issue with Font. [message #32274 is a reply to message #32250] Thu, 05 May 2011 18:46 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Results for test done on Windows XP

STDFONT
Times New Roman
Arial
Courier New
Symbol
Wingdings
Tahoma
System
Terminal
Fixedsys
Roman
Script
Modern
Small Fonts
MS Serif
WST_Czec
WST_Engl
WST_Fren
WST_Germ
WST_Ital
WST_Span
WST_Swed
Courier
MS Sans Serif
Marlett
Lucida Console
Lucida Sans Unicode
Verdana
Arial Black
Comic Sans MS
Impact
Georgia
Franklin Gothic Medium
Palatino Linotype
Trebuchet MS
Webdings
Estrangelo Edessa
Gautami
Latha
Mangal
MV Boli
Raavi
Shruti
Tunga
Sylfaen
Microsoft Sans Serif
Arial Unicode MS
Book Antiqua
Bookman Old Style
Century
Century Gothic
Garamond
MS Outlook
Wingdings 2
Wingdings 3
MS Reference Sans Serif
MS Reference Specialty
方正舒体
方正姚体
华文彩云
华文细黑
华文行楷
华文新魏
华文中宋
隶书
宋体-方正超大字符集
幼圆
Haettenschweiler
Bookshelf Symbol 7
Bitstream Vera Sans
Bitstream Vera Serif
Bitstream Vera Sans Mono
Myriad Web Pro
Myriad Web Pro Condensed
Arial Narrow
Kartika
Vrinda
Lucida Sans
Free 3 of 9 Extended
Free 3 of 9
DejaVu Sans Condensed
DejaVu Serif
DejaVu Serif Condensed
DejaVu Sans Mono
DejaVu Sans
DejaVu Sans Light
OpenSymbol
MS Mincho
MS PMincho
MS Gothic
MS PGothic
MS UI Gothic
Gulim
GulimChe
Dotum
DotumChe
Batang
BatangChe
Gungsuh
GungsuhChe
宋体
新宋体
宋体-PUA
黑体
MingLiU
PMingLiU
微软雅黑


And
rfnt.GetFaceName() = Arial Unicode MS
rfnt.GetFaceName() = Arial Unicode MS
rfnt.GetFaceName() = Arial Unicode MS
rfnt.GetFaceName() = Arial Unicode MS
rfnt.GetFaceName() = MS UI Gothic
rfnt.GetFaceName() = Arial Unicode MS
rfnt.GetFaceName() = MS UI Gothic
rfnt.GetFaceName() = Arial Unicode MS
rfnt.GetFaceName() = Arial Unicode MS
Re: It's suspected to be an issue with Font. [message #32286 is a reply to message #32250] Fri, 06 May 2011 10:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
Lance wrote on Tue, 03 May 2011 08:52

STDFONT
serif
sans-serif
monospace
         <<-----This is the SimSun I suppose, but somehow it
              <<      was skipped and the font below it was chosen.



Ahaaa!

So the reason is that the name of font itself is translated to CJK. No wonder we cannot find it.

OK, the one simple step to prove this theory: Could you switch your windows to English and retest? (I believe that in english, the name would be SimSun, so it could be found).
Re: It's suspected to be an issue with Font. [message #32288 is a reply to message #32286] Fri, 06 May 2011 10:36 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
http://msdn.microsoft.com/en-us/library/dd162620%28v=vs.85%2 9.aspx

"The fonts for many East Asian languages have two typeface names: an English name and a localized name. EnumFonts, EnumFontFamilies, and EnumFontFamiliesEx return the English typeface name if the system locale does not match the language of the font."

Well, well, well, always some surprise waiting to bite us...

I guess the simple fix now is to simply add CJK names to FontCR.cpp, something like:

struct sRFace {
	const char *name;
	dword l, h;
} sFontReplacements[] = {
	{ "sans-serif", 0xffee0008, 0xdc000801 },
	{ "Arial", 0xfffe0000, 0x09c00080 },
	{ "Arial Unicode MS", 0xfffc3fef, 0xfa7ff7e7 },
	{ "SimSun", 0xfd800000, 0x09ffff00 },
	{ "方正舒体", 0xfd800000, 0x09ffff00 },
	{ "MS UI Gothic", 0xffc01008, 0x0fffff00 },
	{ "MS Mincho", 0xffc01008, 0x0fffff00 },


Above CJK glyphs are just example, please replace with CJK name (I cannot read CJK Smile. Perhaps, if you can, there are more fonts with possibly alternate CHJ name in the table, they would need the same treatment.
Re: It's suspected to be an issue with Font. [message #32295 is a reply to message #32288] Fri, 06 May 2011 14:59 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
I see. Is it that the linux world also follows MS principle on this regard?

I will do some test and report the result.

Thanks!
Re: It's suspected to be an issue with Font. [message #32296 is a reply to message #32295] Fri, 06 May 2011 17:51 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Hi Mirek:

It works, even though not in the intended way.

I couldn't do it on Windows as the UTF-8 Chinese characters representation will fail MSVC and I don't have MinGW installed yet. But the test on Linux works beautifully. All previously invisible characters now display properly. Placement issue also disappears.

Only strange thing is that I use StdFont, and edit the name in sFontReplacements[] for SimSun only, but the Replacement font actually used is WenQuanYi Zen Hei, which is sans serif while SimSum is serif.

So it seemed edit the name of SimSun (that's the only entry I edited) makes WenQuanYi Zen Hei take precedence over UnDotum which would otherwise be selected.
Re: It's suspected to be an issue with Font. [message #32297 is a reply to message #32296] Fri, 06 May 2011 19:18 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
Lance wrote on Fri, 06 May 2011 11:51

Hi Mirek:

It works, even though not in the intended way.

I couldn't do it on Windows as the UTF-8 Chinese characters representation will fail MSVC and I don't have MinGW installed yet.



Ah, we have met this MSVC issue before...

The thing to do is that you will have to convert <32 >128 characters in string to escapes (octal or hexadecimal).

One way is to use this 'script'

#include <Core/Core.h>

using namespace Upp;

CONSOLE_APP_MAIN
{
	DLOG(AsCString("方正舒体", INT_MAX, NULL, ASCSTRING_OCTALHI));
}


and then paste text from log. Of course, you need to do that in Linux Smile

Quote:


Only strange thing is that I use StdFont, and edit the name in sFontReplacements[] for SimSun only, but the Replacement font actually used is WenQuanYi Zen Hei, which is sans serif while SimSum is serif.



Sounds weird...

Well, whatever. If I may ask you, please fix that table by adding 'cjk' names and post here, so that it can be fixed in svn...
Re: It's suspected to be an issue with Font. [message #32301 is a reply to message #32297] Sat, 07 May 2011 03:42 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Mirek:

Regarding MSVC character set issue, the suggested way doesn't seem to work all the time. For example, the T file for GridCtrl used to cause trouble with MSVC for zhTW; then recent version of the T file apparently change to the the octel escaped version suggested by you, but it still fails MSVC on my computer, while similarly escaped Russian etc translations are just fine. I don't know exactly why.

As for the sFontReplacements array translation part, I will do in the way you suggested. I guess I will need to put 4 fonts entries: two for the typical serif/sans serif fonts on Windows, and 2 for the counterpart fonts on Linux.

Update: I might be wrong. GridCtrl's T file is no longer causing compilation trouble on Windows.

[Updated on: Sun, 15 May 2011 01:26]

Report message to a moderator

Re: It's suspected to be an issue with Font. [message #32302 is a reply to message #32301] Sat, 07 May 2011 04:00 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
OK, here is what I am going to do:

1. On Windows(Linux), run our test program to enumerate fonts. Filter out non-chinese fonts.

2. Transalate to octet escaped version for font names when necessary

3. Create an entry for each of the font name, with the most favorate 4 fonts ( serif/sans serfi on win/lin) listed on top of all chinese font entries.

4. Post the result to this thread.

If you have a better plan, please let me know. Thanks!
Re: It's suspected to be an issue with Font. [message #32303 is a reply to message #32302] Sat, 07 May 2011 05:19 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
	{"\346\226\260\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 },//SimSun (or New Song Ti)
	{"\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 }, // Song Ti
	{"\345\276\256\350\275\257\351\233\205\351\273\221", 0xfd800000, 0x09ffff00 }, //MS Ya Hei
	{"\351\273\221\344\275\223", 0xfd800000, 0x09ffff00 },  // Hei Ti
	{"\346\226\207\346\263\211\351\251\277\346\255\243\351\273\221", 0xfd800000, 0x09ffff00 }, //WenQuanYi Zheng Hi
	{"\346\226\207\346\263\211\351\251\277\347\255\211\345\256\275\345\276\256\347\261\263\351\273\221", 0xfd800000, 0x09ffff00 },//WenQuanYi Wei Hei
	{"\344\273\277\345\256\213", 0xfd800000, 0x09ffff00 }, //Fang Song
	{"\346\245\267\344\275\223", 0xfd800000, 0x09ffff00 }, // Kai Ti


Above entries should covered the most common and acceptible fonts on both MS and Linux(ubuntu, free fonts) platforms. I am not sure if it will work as well for HongKong/Taiwan/Korean/Japanese users. But now we know where to go to fix similar issues.

Thanks for your effort. U++ becomes more frienldy to CJK users because of it!

I will build the TheIDE with the above entries applied and see how well it works on Linux(Ubuntu) and Windows, and will report the results hopefully within the next 24 hours.
Re: It's suspected to be an issue with Font. [message #32304 is a reply to message #32303] Sat, 07 May 2011 06:01 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Works beautifully on Linux.

On windows, I noticed the font replacement has some issue. See attached picture:

index.php?t=getfile&id=3226&private=0

The second Chinese character is notably larger. I believe a different font is applied to it, possibly because it's not represented in the first font which other characters uses.

I will twink the ordering of the entries a little bit for best results.

  • Attachment: fontOnWin.jpg
    (Size: 23.58KB, Downloaded 708 times)
Re: It's suspected to be an issue with Font. [message #32305 is a reply to message #32304] Sat, 07 May 2011 08:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
OK, I will wait for your reordering attempt, then apply to svn.
Re: It's suspected to be an issue with Font. [message #32306 is a reply to message #32305] Sat, 07 May 2011 14:59 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Hi Mirek:

Sorry for keeping you waiting.

Here is the adjusted sFontReplacements array

struct sRFace {
	const char *name;
	dword l, h;
} sFontReplacements[] = {
	{ "sans-serif", 0xffee0008, 0xdc000801 },
	{ "Arial", 0xfffe0000, 0x09c00080 },
	{"\346\226\260\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 },//SimSun (or New Song Ti)
	{"\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 }, // Song Ti
	{"\345\276\256\350\275\257\351\233\205\351\273\221", 0xfd800000, 0x09ffff00 }, //MS Ya Hei
	{"\351\273\221\344\275\223", 0xfd800000, 0x09ffff00 },  // Hei Ti
	{"\346\226\207\346\263\211\351\251\277\346\255\243\351\273\221", 0xfd800000, 0x09ffff00 }, //WenQuanYi Zheng Hi
	{"\346\226\207\346\263\211\351\251\277\347\255\211\345\256\275\345\276\256\347\261\263\351\273\221", 0xfd800000, 0x09ffff00 },//WenQuanYi Wei Hei
	{"\346\245\267\344\275\223", 0xfd800000, 0x09ffff00 }, // Kai Ti
	{"\344\273\277\345\256\213", 0xfd800000, 0x09ffff00 }, //Fang Song
	{ "Arial Unicode MS", 0xfffc3fef, 0xfa7ff7e7 },
	{ "MS UI Gothic", 0xffc01008, 0x0fffff00 },
	{ "MS Mincho", 0xffc01008, 0x0fffff00 },
	{ "VL Gothic", 0xfd800000, 0x09a7ff80 },
	{ "VL PGothic", 0xffe00008, 0x0de7ff80 },
	{ "UnDotum", 0xe5800000, 0x0aa7ff7e },
	{ "UnBatang", 0xe5800000, 0x0aa7ff7e },
	{ "DejaVu Sans Mono", 0xffec0004, 0x0fc00080 },
	{ "DejaVu Sans", 0xfffd000c, 0x0fc40080 },
	{ "AlArabiyaFreeSerif", 0xffdc0008, 0xd8000007 },
	{ "Kochi Mincho", 0xffdc0008, 0xd8000007 },
	{ "Kochi Gothic", 0xffdc0008, 0xd8000007 },
	{ "Sazanami Mincho", 0xffdc0008, 0xd8000007 },
	{ "Sazanami Gothic", 0xffdc0008, 0xd8000007 },
	{ "Gulim", 0xf7c00000, 0x0ba7ff7e },
	{ "PMingLiU", 0xff800000, 0x09ffff00 },
	{ "FreeSans", 0xfff23d00, 0x0fc00000 },
	{ "FreeSerif", 0xfffd3938, 0x0fc00080 },
	{ "Symbol", 0xe4000000, 0x88000002 },
};


Turns out "Arial Unicode MS" is the culprit. Some Chinese characters will be intercepted by it.

Not all the entries are strictly necessary. The first two Chinese fonts, Song Ti and SimSun(New Song Ti) are generally available on Windows and Linux platform. They are serif fonts. SongTi(or SimSun) is the most popular/common font. Most Chinese Characters should be implemented in this(these two) font. In the past, I noticed on Linux platform that some supposedly Hei Ti font were actually rendered using Song Ti because those characters are not implemented in Hei Ti. Sorry for my expression but you know what I mean.

So if Upp doesn't actually differentiate between Serif/Sans Serif in font replacement logic, we should be able to keep the SongTi and SimSun entries only and eliminate other Chinese Font entries.

Thank you again for your attention to this issue! It's very important to me.


Edited by Lance, Reason: SimSun is the way to go. Tried Fang Song, looks great, but apparently it has much smaller implemented character set.

[Updated on: Sat, 07 May 2011 15:17]

Report message to a moderator

Re: It's suspected to be an issue with Font. [message #32307 is a reply to message #32306] Sat, 07 May 2011 15:29 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Sorry, one more issue. Refer to the following picture:

index.php?t=getfile&id=3227&private=0

Notice when I draw it in the plain and simple way in MyApp, the text are compact and nice looking while in TheIDE code editor the same characters looks worse because of the exessive space in between.

If you can make theide code editor display Chinese character as compact as in MyApp or as it displays StdFont, that would be great. If too complicated then forget it.
Re: It's suspected to be an issue with Font. [message #32308 is a reply to message #32307] Sat, 07 May 2011 17:39 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Sorry but it's getting more complicated than we had expected.

I did test on another Windows XP machine. Here is the font replacement table:
struct sRFace {
	const char *name;
	dword l, h;
} sFontReplacements[] = {
	{ "sans-serif", 0xffee0008, 0xdc000801 },
	{ "Arial", 0xfffe0000, 0x09c00080 },
	{"\346\226\260\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 },//SimSun (or New Song Ti)
	{"\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 }, // Song Ti
	{"\345\276\256\350\275\257\351\233\205\351\273\221", 0xfd800000, 0x09ffff00 }, //MS Ya Hei
	{"\351\273\221\344\275\223", 0xfd800000, 0x09ffff00 },  // Hei Ti
	
	{ "Arial Unicode MS", 0xfffc3fef, 0xfa7ff7e7 },
	{ "SimSun", 0xfd800000, 0x09ffff00 },
	{ "MS UI Gothic", 0xffc01008, 0x0fffff00 },
	{ "MS Mincho", 0xffc01008, 0x0fffff00 },
	{ "WenQuanYi Zen Hei Mono", 0xfd800000, 0x0ae7ff7e },
	{ "WenQuanYi Zen Hei", 0xfd800000, 0x0ae7ff7e },
	{ "VL Gothic", 0xfd800000, 0x09a7ff80 },
	{ "VL PGothic", 0xffe00008, 0x0de7ff80 },
	{ "UnDotum", 0xe5800000, 0x0aa7ff7e },
	{ "UnBatang", 0xe5800000, 0x0aa7ff7e },
	{ "DejaVu Sans Mono", 0xffec0004, 0x0fc00080 },
	{ "DejaVu Sans", 0xfffd000c, 0x0fc40080 },
	{ "AlArabiyaFreeSerif", 0xffdc0008, 0xd8000007 },
	{ "Kochi Mincho", 0xffdc0008, 0xd8000007 },
	{ "Kochi Gothic", 0xffdc0008, 0xd8000007 },
	{ "Sazanami Mincho", 0xffdc0008, 0xd8000007 },
	{ "Sazanami Gothic", 0xffdc0008, 0xd8000007 },
	{ "Gulim", 0xf7c00000, 0x0ba7ff7e },
	{ "PMingLiU", 0xff800000, 0x09ffff00 },
	{ "FreeSans", 0xfff23d00, 0x0fc00000 },
	{ "FreeSerif", 0xfffd3938, 0x0fc00080 },
	{ "Symbol", 0xe4000000, 0x88000002 },
};


Here is the result of font enumeration on the machine:
STDFONT
Times New Roman
Arial
Courier New
Symbol
Wingdings
Tahoma
System
Terminal
Fixedsys
Roman
Script
Modern
Small Fonts
MS Serif
WST_Czec
WST_Engl
WST_Fren
WST_Germ
WST_Ital
WST_Span
WST_Swed
Courier
MS Sans Serif
Marlett
Lucida Console
Lucida Sans Unicode
Verdana
Arial Black
Comic Sans MS
Impact
Georgia
Franklin Gothic Medium
Palatino Linotype
Trebuchet MS
Webdings
Estrangelo Edessa
Gautami
Latha
Mangal
MV Boli
Raavi
Shruti
Tunga
Sylfaen
Microsoft Sans Serif
Arial Unicode MS
Book Antiqua
Bookman Old Style
Century
Century Gothic
Garamond
MS Outlook
Wingdings 2
Wingdings 3
MS Reference Sans Serif
MS Reference Specialty
方正舒体
方正姚体
华文彩云
华文细黑
华文行楷
华文新魏
华文中宋
隶书
宋体-方正超大字符集
幼圆
Haettenschweiler
Bookshelf Symbol 7
Bitstream Vera Sans
Bitstream Vera Serif
Bitstream Vera Sans Mono
Myriad Web Pro
Myriad Web Pro Condensed
Arial Narrow
Kartika
Vrinda
Lucida Sans
Free 3 of 9 Extended
Free 3 of 9
DejaVu Sans Condensed
DejaVu Serif
DejaVu Serif Condensed
DejaVu Sans Mono
DejaVu Sans
DejaVu Sans Light
OpenSymbol
MS Mincho
MS PMincho
MS Gothic
MS PGothic
MS UI Gothic
Gulim
GulimChe
Dotum
DotumChe
Batang
BatangChe
Gungsuh
GungsuhChe
宋体                              <----- This is Song Ti
新宋体                            <------ This is SimSun
宋体-PUA
黑体
MingLiU
PMingLiU
微软雅黑
f.GetFaceName() = Arial Unicode MS
f.GetFaceName() = Arial Unicode MS
f.GetFaceName() = Arial Unicode MS
f.GetFaceName() = Arial Unicode MS



And here is the font substitution report:
f.GetFaceName() = Arial Unicode MS
f.GetFaceName() = MS UI Gothic
f.GetFaceName() = Arial Unicode MS
f.GetFaceName() = Arial Unicode MS


And the text use to generate the substitution result is 颜色不错.

SimSun and Song Ti are skipped even though the font are present in the system and they are supposed to take precedence over Arial Unicode MS and MS UI Gothic. The more weired thing is it works just fine on Windows Vista and Ubuntu. Will do a test on a Windows 7 Machine.
Re: It's suspected to be an issue with Font. [message #32309 is a reply to message #32308] Sat, 07 May 2011 19:47 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
In a newly installed machine with Windows 7 Home Premium English version and VC10 Chinese installed, I discovered that chinese font name are in English or Pinyin. And neither Song Ti or SimSun is present, while Microsoft YaHei is the default. I can confirm this is yet another SongTi. On Windows Machine Microsoft YaHei and its Chinese alias ΢ź should be a safe bet, and it looks decent even in small font size. So the following revised entries and ordering should work on most machine.

struct sRFace {
	const char *name;
	dword l, h;
} sFontReplacements[] = {
	{ "sans-serif", 0xffee0008, 0xdc000801 },
	{ "Arial", 0xfffe0000, 0x09c00080 },
	{"\346\226\260\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 },//SimSun (or New Song Ti)
	{"SimSun", 0xfd800000, 0x09ffff00 },//SimSun (or New Song Ti)
	{"\345\256\213\344\275\223", 0xfd800000, 0x09ffff00 }, // Song Ti
	{"\345\276\256\350\275\257\351\233\205\351\273\221", 0xfd800000, 0x09ffff00 }, //MS Ya Hei
	{"Microsoft YaHei", 0xfd800000, 0x09ffff00 }, //MS Ya Hei
//	{"\351\273\221\344\275\223", 0xfd800000, 0x09ffff00 },  // Hei Ti
//	{"\346\226\207\346\263\211\351\251\277\346\255\243\351\273\221", 0xfd800000, 0x09ffff00 }, //WenQuanYi Zheng Hi
//	{"\346\226\207\346\263\211\351\251\277\347\255\211\345\256\275\345\276\256\347\261\263\351\273\221", 0xfd800000, 0x09ffff00 },//WenQuanYi Wei Hei
//	{"\344\273\277\345\256\213", 0xfd800000, 0x09ffff00 }, //Fang Song
//	{"\346\245\267\344\275\223", 0xfd800000, 0x09ffff00 }, // Kai Ti
	{ "Arial Unicode MS", 0xfffc3fef, 0xfa7ff7e7 },
	{ "MS UI Gothic", 0xffc01008, 0x0fffff00 },
	{ "MS Mincho", 0xffc01008, 0x0fffff00 },
	{ "VL Gothic", 0xfd800000, 0x09a7ff80 },
	{ "VL PGothic", 0xffe00008, 0x0de7ff80 },
	{ "UnDotum", 0xe5800000, 0x0aa7ff7e },
	{ "UnBatang", 0xe5800000, 0x0aa7ff7e },
	{ "DejaVu Sans Mono", 0xffec0004, 0x0fc00080 },
	{ "DejaVu Sans", 0xfffd000c, 0x0fc40080 },
	{ "AlArabiyaFreeSerif", 0xffdc0008, 0xd8000007 },
	{ "Kochi Mincho", 0xffdc0008, 0xd8000007 },
	{ "Kochi Gothic", 0xffdc0008, 0xd8000007 },
	{ "Sazanami Mincho", 0xffdc0008, 0xd8000007 },
	{ "Sazanami Gothic", 0xffdc0008, 0xd8000007 },
	{ "Gulim", 0xf7c00000, 0x0ba7ff7e },
	{ "PMingLiU", 0xff800000, 0x09ffff00 }, // <--- SHOULD MOVE UP
	{ "FreeSans", 0xfff23d00, 0x0fc00000 },
	{ "FreeSerif", 0xfffd3938, 0x0fc00080 },
	{ "Symbol", 0xe4000000, 0x88000002 },
};



I still cannot figure out why it would not work on my Windows XP machine. (it's Win XP Professional English version, but many Chinese software has been installed/uninstalled, so its precise condition cannot be determined and reproduced. One thing is for sure, Chinese character in MS Office or OpenOffice are just fine). I will do further investigation. If you can give me some ideas on how to figure out the exact trouble point, I would appreciate that.

Edit: Promote entry for PMingLiu to above that for Arial Unicode MS solve the problem on the WinXP machine. The reason is still unknown. Even though SimSun, SongTi, MS YaHei all are present and work just fine in MS Office and probably many other programs, and enumeration in U++ also shows them, they will somehow report false information to UPP font substitution logic so that they are eliminate as viable candidates.

[Updated on: Sun, 08 May 2011 00:40]

Report message to a moderator

Re: It's suspected to be an issue with Font. [message #32311 is a reply to message #32309] Sat, 07 May 2011 20:41 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Sorry for throwing too much at you. Here I discovered another issue which I believe is related to Upp way of interpreting UTF-8 characters.

This special Chinese punctuation mark, ""(wide comma,"\357\274\214"), will not display and it will cause otherwise displayable Chinese characters following it disappear.

Here is a test program:
#include <CtrlLib/CtrlLib.h>

using namespace Upp;

struct MyApp : TopWindow {
	virtual void Paint(Draw& w) {
		const char * texts[]={
			"\346\234\213", //PENG
			"\345\217\213",  //YOU
			"\346\234\213\357\274\214\345\217\213",//PENG CHINESECOMMA YOU
			"\346\234\213\345\217\213\357\274\214\346\234\213\345\217\213" // PENG YOU CHINESECOMMA PENG YOU
		};

		w.DrawRect(GetSize(), White);
		for(int i=0; i<4; ++i)
			w.DrawText(10, 10+i*30, texts[i]);
	}
};
GUI_APP_MAIN
{
	MyApp().Run();
}


Output is something like:
index.php?t=getfile&id=3229&private=0




A second issue: On Ubuntu, I applied the above changes to font substitution table and recompiled theide, the Chinese font displays perfect, but this time the input method won't work. Chinese characters entered in the code editor are displayed as narrow blanks, when copy&pasting the blanks to gedit, gedit also display blanks; copy good text from web page or gedit to the code editor works fine.
  • Attachment: WideComma.png
    (Size: 17.71KB, Downloaded 649 times)

[Updated on: Sat, 07 May 2011 23:30]

Report message to a moderator

Re: It's suspected to be an issue with Font. [message #32314 is a reply to message #32311] Sat, 07 May 2011 23:10 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Quote:


A second issue: On Ubuntu, I applied the above changes to font substitution table and recompiled theide, the Chinese font displays perfect, but this time the input method won't work. Chinese characters entered in the code editor are displayed as narrow blanks, when copy paster the blanks to gedit, gedit also display blanks; copy good text from website or gedit to the code editor works fine.



Regarding this issue, here is some results of my further experiments. It has been re-confirmed with the most recent version 3407. The test was done on a Ubuntu. G++ is 64bit. The patch to font replacement table has been applied.

When I compile theide using GCC Debug mode, the ide works beautifully: font is pretty, input method works fine; all is good, well almost, as the chinese wide comma issue remains.

When I compile theide using GCC Optimal mode, the ide display existing chinese fonts as well, but Chinese input method doesn't work. Strange, non-displayable characters are inserted, who are invisible to me but will fail the compiler.

BTW, the ide "version.h" file reads:
 
#define IDE_VERSION    "3274-lucid-i386-nogtk"


As this is a pretty old version, the actually nightly release version may already have this issue fixed. That I wouldn't know.
Re: It's suspected to be an issue with Font. [message #32315 is a reply to message #32314] Sat, 07 May 2011 23:25 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Mirek, if you want a quick status regarding where we are, here you go:

1. Apply the changes to Font Substitution Table as in message #32309 will fix 90% of the problem on both Linux and windows platforms.

2. There is a Wide Comma issue needs further investigation. See message #32311

3. There is a possible [Chinese]Input Method problem. We don't know if it actually exists in the current version of theide; if it does, I am not sure if it's caused by our change to the Font Substitution Table. For some symptom or for double check, please refer to latter part of message #32311 and message #32314.
Re: It's suspected to be an issue with Font. [message #32320 is a reply to message #32315] Mon, 09 May 2011 05:55 Go to previous messageGo to next message
Lance is currently offline  Lance
Messages: 347
Registered: March 2007
Senior Member
Hi Mirek:

I found out that the WideComma issue is independent of Font Substitution Table. It's even independent of Chinese Characters. The symptom can be further generalized as the following:

1. a string, say "abc" will paint correctly.
2. the WideComma(and WideQuestionMark, maybe more) follows it ("abc") will not display;
3. otherwise good text, say "abc", following the WideComma, will not show
4. If select the WideComma only, or the text following it, the text become visible.

I believe the problem most likely happens in the process of translating the WideComma (or WideQuestionMark) from utf-8 to WString(wchar_t?)
Re: It's suspected to be an issue with Font. [message #32370 is a reply to message #32315] Fri, 13 May 2011 12:30 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 12098
Registered: November 2005
Ultimate Member
Lance wrote on Sat, 07 May 2011 17:25

Mirek, if you want a quick status regarding where we are, here you go:

1. Apply the changes to Font Substitution Table as in message #32309 will fix 90% of the problem on both Linux and windows platforms.



Applied.

Quote:


2. There is a Wide Comma issue needs further investigation. See message #32311



Fixed.

Quote:


3. There is a possible [Chinese]Input Method problem. We don't know if it actually exists in the current version of theide; if it does, I am not sure if it's caused by our change to the Font Substitution Table. For some symptom or for double check, please refer to latter part of message #32311 and message #32314.



Going to look into it now... Difficult, as I do not know how to install or use input methods Smile

Mirek
Previous Topic: There are too short lines after synchronization. t files.
Next Topic: A proposal: Adding a Translation & Localization GUI to TheIDE
Goto Forum:
  


Current Time: Fri Nov 15 13:41:59 CET 2019

Total time taken to generate the page: 0.01525 seconds