<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I do not know about the internals of Trestle but I have some
knowledge<br>
of the X core protocol and thus I know that everything related to
XIM<br>
is very complicated though usage of XIM rather than just
XDrawString16<br>
would enable user input of Asian languages.<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>