OK, The idea to take UTF8 as future's main coding method is a good idea. But now in china, 2 byte chinese character mix with 1 byte english character in ANSI text is widly spreaded. A free editor software Notepad++ support this mode.
As your wish, I provide the UTF8 chinese text in hex format as following: ef bb bf 20 20 31 20 e5 b9 bf e8 a5 bf e5 8c 97 e9 83 a8 e6 b9 be e6 b5 b7 e5 9f 9f e6 b5 b7 e4 b8 8a e6 b2 bb e5 ae 89 e5 9f ba e7 a1 80 e4 bf a1 e6 81 af e7 b3 bb e7 bb 9f 32 20 e7 ae a1 e7 90 86 33 20 e7 ae a1 e7 90 86 e6 b8 af e5 8f a3 e7 a0 81 e5 a4 b4 34 20 e7 ae a1 e7 90 86 e5 85 bb e6 ae 96 e5 9c ba 35 20 e7 ae a1 e7 90 86 e6 b8 94 e8 88 b9 36 20 e7 ae a1 e7 90 86 e6 b8 94 e6 b0 91 37 20 e7 b3 bb e7 bb 9f 38 20 e5 b8 ae e5 8a a9 39 20 e9 80 80 e5 87 ba ff I save this text in a UTF8 text file, and read it into memory in my app, Then assign them to widget label and menu item. some of the text are display in mess. What make me upset is that this phenomenon is not consistant, for example, I run the app, I found a menu item is display in mess, when I quit the app ,and run again ,it maybe display correct on the certain item ,but another item is display wrong which works good in previous run. > > > > I have try to compiler fltk 1.3 with my code. most=20 > > chinese characters are display well, and editing chinese=20 > > works well. > > At least that is a start! > > > But it still has some problem. In window label=20 > > and menu label ,some chinese are still displayed in mess.=20 > > OK - do you know if this is happening simply because the selected font > does not have glyphs for these characters, or is it because the code > point for the characters is encoded incorrectly in some way? > > What are the Unicode code points for the failing glyphs? Are they from > the BMP (Basic Multilingual Plane) or from one of the "higher level" > planes? > > Can you post some example strings that fail? (Ideally, as an array of > the underlying bytes rather than a string...) And some that work, and > maybe some that are a bit of both? > > > According to my experience, utf8 support chinese not good=20 > > enough. Not only in fltk,but also in some web pages and=20 > > emails. > > My experience has been the exact opposite; UTF-8 seems to be more > reliable, and where it has failed, it is because the input strings were > not well formed, not because the UTF-8 mechanism did not work. > That said, I am sure you have considerably more experience with Chinese > text handling than I do, of course! > There are many Chinese, Japanese and Korean contributors to the Unicode > project, so I imagine they must be working to make it a credible > solution. > > > So I decline to an old method in china, that is ,=20 > > using ANSI coding, when encounter a byte that greater than=20 > > 127, treat it as 2 byte character, but be careful, it need to=20 > > match 2 byte words analysising the whole line. > > So,My proposal is , provid a code page option in fltk, so=20 > > that app developer can choice UTF8 or ANSI or other. > > An other option is, in character processing , use=20 > > std::_wstring instead of char* . > > I don't think there is any prospect of us switching to a wide-character > mechanism like that. They are hard to maintain (harder than UTF-8), > suffer from endian-ness issues, are not very portable, and there are too > many different variants... > > UTF-8 gives reasonably effcient encoding, does not suffer from endian > issues, maps easily onto the Unicode code points and is available on > every platform we support, so it really is the only credible choice. It > is also the choice that all the operating systems we support have made - > even MS have embraced UTF-8 as a string encoding. > > The archaic mechansims of code pages and platform specific multi-byte > encodings is an absolute nightmare to support, and no really workable > cross-platform standard exists (other than the multi-byte UTF encodings, > and if you are switching to one of them, you might as well go UTF-8 > anyway...) > > > > > > > SELEX Sensors and Airborne Systems Limited > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex= > SS14 3EL > A company registered in England & Wales. Company no. 02426132 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
