Ola,
Don't you just love how UNICODE is not haphazardly implemented? That was
sarcasm, by the way. My solution for all this UNIversal lack of communication
and understanding of UNICODE implementation, was to create a few function
calls of my own to translate on-the-fly between UTF-16 and UTF-8, and between
UTF-8 and GB18030. Why UTF-16? Because it has the most native support from
Microsoft and much of the Windows internals are in UTF-16 (NTFS especially
comes to mind). Why GB18030? Because GB18030 is the only UNICODE
implementation so far that has actually been standardized in at least one
country (China, with an audience of 1.5 billion customers). I wish IUP would
directly support GB18030 so I could eliminate half of the translations needed
(Antonio tells me that IUP will contain a GB18030 preprocessor flag for
providing GB18030 support). Why UTF-8? Because UTF-8 is a central part of this
translation process because IUP does directly support UTF-8 with the following
commands:
UTF8MODE [Windows and GTK Only]. By default IUP uses strings in the current
locale (See FONT attribute). To use UTF-8 strings set this attribute to Yes.
Default: NO.
UTF8MODE_FILE [Windows Only]. By default IUP uses file names in the current
locale, even when UTF8MODE=Yes. To use UTF-8 file names set this attribute to
Yes. Default: NO.
Gracias,
Andrew
On 2019-05-14 at 5:45 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote:
Hi,
Interesting. I saw that you did this:
if (sizeof(ImWchar) == 2)
cp = 0xFFFD;
We use the TCHAR definition which is a 16 bits value when UNICODE is defined
(the default in IUP), i.e. sizeof==2 by default. So we don't actually need the
"Surrogate" variable storage but just to replace the surrogate pair by 0xFFFD.
Is that correct?
Best,
Scuri
Em qui, 9 de mai de 2019 às 04:45, 云风 Cloud Wu <clou...@gmail.com> escreveu:
IupGLText can't handle surrogate pairs (
https://en.wikipedia.org/wiki/UTF-16 ) now.
In windows, a unicode above U+10000 (For example U+1F604 😀 ) will be
separated into two WM_CHAR messages. If we got a WM_CHAR with WPARAM
between 0xD800 to 0xDBFF , we should wait for another part of
surrogate pair, and combine them into one unicode code point.
btw, I fix the same issue for imgui . This patch (
https://github.com/ocornut/imgui/pull/2541/commits/fc2dff0ab602e77628a97edd983f03f6f571487a
) is for your reference.
--
http://blog.codingnow.com
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
