<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Actually the devil is in the details:<br>
Continuing to use 16bit characters outputting strings would be easy.<br>
However when it comes to adjust the input function there is no<br>
XKeySymToKeyCode16 function which means that you would either<br>
have to implement one on your own or the other way upgrade to<br>
X11R6, use XIM and convert from UTF-32 to UTF-16. Well there is<br>
a possibility to use XIM functions right the way as an <br>
XKeySymToKeyCode32 function would work without any input <br>
or status reflection.<br>
In order to use XOM for outputting 32 bit characters you would<br>
have to use 'font sets' on the other hand which I personally have<br>
never done.<br>
<br>
Elmar<br>
<br>
<br>
<div class="moz-cite-prefix">Am 30.11.2013 11:25, schrieb Elmar
Stellnberger:<br>
</div>
<blockquote cite="mid:5299CB2B.9090008@elstel.org" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
> Right, In this respect, everything probably just works and
always has.<br>
> Just don't try to display any two non-English languages in a
GUI at once.<br>
<br>
That was exactly the requirement: use greek and latin characters
at the same time to display mathematical expressions<br>
<br>
> I think we should port Trestle to use 16 bit characters
always internally.<br>
> Even going so far as to double the memory use of common
English strings.<br>
<br>
No, that does not double the memory usage. I have just inserted a
Text.IsWide function to let a future<br>
version of VBT.PaintText select whether it wants to use
XDrawString16 or its eight bit counterpart.<br>
<br>
> Can anyone vouch for XDrawString16 generally being
implemented and working?<br>
<br>
Yes it is shipped with X11R4<br>
<br>
- Jay<br>
<br>
> 1) Ok for purposes of interfacing with Win32 and Xlib, what
should I use where WIDECHAR used to be correct?<br>
> 2) Are we really certain that redefining WIDECHAR is the way
to go?<br>
> Not, say, introduce a new time, CHAR32 or UCHAR32?<br>
> And maybe add an explicit alias CHAR16 or UCHAR16 to provide
a type that nobody will ever consider changing?<br>
<br>
upgrading to WideChar32 would AFAIK be a major effort, not a
simple fix:<br>
first you would have to upgrade the whole Trestle kit to X11R6<br>
you would have to use the very heavy weight X11R6 XIM interface to
make use of WideChar32<br>
then you would finally have to change the internal representation
of the Text type.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Am 30.11.2013 11:02, schrieb Dragiša
Durić:<br>
</div>
<blockquote
cite="mid:8724DFC8-DDD0-49C3-8232-835E30268A86@m3w.org"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
I think this would be a major error. Choose 16bit route when
only Windows does this, and everybody else is using UTF-8 is not
a logical decision.<br>
</blockquote>
I do not consent. WideChar32 will come with the additional benefit
of some additionally supported languages. That is all it would be
good for.<br>
If we ever upgraded to use XIM which will be a major effort as I
have already tried to point out we can still consider WC32 though
converting<br>
between UTF-8 and UTF-16 is no big deal (I have an implementation
which I could give you.).<br>
<br>
i.e. X11R4 uses WC16<br>
X11R6-XIM uses WC32<br>
<br>
I do not want to speak against WC32; Nonetheless<br>
it basically depends on how much effort you are willing to invest.<br>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>