[cmake-developers] Future of ccmake and cmake-gui and internationalization

[Alan W. Irwin]

On 2017-08-16 23:27-0700 Eric Wing wrote:

>> <off topic>
>> Thanks to your post the possibility now exists that I or one of my
>> PLplot colleagues will develop an IUP-based device driver in the
>> intermediate future. So if that occurs I would plan to download and
>> build IUP for myself on Linux.  And that would put me in a position to
>> do the above simple test myself. But that is in the speculative
>> future and only for the GTK+ backend case.  So your test results now
>> on this unicode and CTL question for as many of the IUP backends as
>> possible would be much appreciated.
>> </off topic>
>
> I'll be honest, string encodings are not my strong suit. What I can
> say is that IUP is developed in Brazil where they speak Portuguese. So
> I know being able to at least support their language is important to
> them, so I hope that means they got a lot of the string encoding stuff
> right. For the Cocoa implementation, IUP has a mode called UTF8 mode
> and I am basically enforcing that it is on for Mac. For every C string
> I have to bridge, I hand it to the native Cocoa UTF8 APIs that convert
> back and forth between C strings and NSStrings (native Cocoa string
> type). I did have some fellow Cocoa devs review my code and run a few
> tests, and they believed it was correct. Though it was not exhaustive.
> If the implementation is wrong, I would like to correct it.

Hi Eric:

I knew nothing about UTF-8 and unicode ~10 years ago, but it is
essential developer knowledge that is well worth having (even if you
only have knowledge of one human language, which is my case). 
Furthermore, it is actually quite simple to pick up this unicode and
CTL knowledge these days (compared to a decade ago).  The reason for
that simplicity is for any decent editor such as emacs or vi you can
cut and paste any UTF-8 string right from any website directly into
your source code, and it normally "just works".

So my advice to test your Mac OS backend for CTL capability is instead of the simple test case
given at
<http://webserver2.tecgraf.puc-rio.br/iup/en/tutorial/tutorial2.html>

use instead

#include <stdlib.h>
#include <iup.h>

int main(int argc, char **argv)
{
   IupOpen(&argc, &argv);

   IupMessage("Hello World 1 ﺳﻼم", "Hello world from IUP ﺳﻼم.");

   IupClose();
   return EXIT_SUCCESS;
}

where the only change I have made to the original is I have appended the utf-8 encoded "ﺳﻼم" to each of those
IupMessage string arguments.

If your mailer is not unicode or CTL aware so you cannot see that
utf-8 encoded Arabic Peace word in this e-mail, cut and paste that
word from the third word in the line that starts with "Pace" in
<http://www.columbia.edu/~fdc/pace/> into the two IupMessage string
arguments.

Then build that modified app and see whether the GUI renders that word
in the same character order that word is rendered by your browser for 
<http://www.columbia.edu/~fdc/pace/>.  (Browsers such as firefox and
konqueror are typically the gold standard for being CTL-aware.)

If that rendering is in the correct order (right-to-left) as given by
firefox you have passed this simple CTL support test for
whichever backend you are using.

Also, you can test the CTL capability of cmake-gui (as well as the
cmake application) by using

option("ﺳﻼم" "ﺳﻼم" ON)

in a simple test project where those two utf-8 strings are cut and
pasted from the above "pace" website.  The result of that test here is
the letters in those words are rendered in the same order as in the
above "pace" website both in the GUI (for the cmake-gui case) and in
CMakeCache.txt (for both the cmake and cmake-gui cases).  And, of
course, if/when an IUP-based cmake-gui is developed, the same CTL test
should be applied to that result as well.

Note also, you don't have to limit your tests just to the word
for Peace in Arabic.  For example, there are some good test
words in <https://en.wikipedia.org/wiki/Complex_text_layout> that
can be cut and pasted.

Finally, in my last post I stated that it would be bad news for IUP if
any of its backends failed the CTL test, but in retrospect that is too
strong a statement.  For example, if the CTL capabilities of IUP are
fine for GTK+, Windows, and Mac OS X backends, but the Motif backend
(used on commercial Unices) is not capable of CTL, then that only
affects the internationalization capabilities of cmake-gui for a
minority platform (Commercial Unices).  And given that the only bad
result if CTL fails is the characters are rendered in the wrong order
in the cmake-gui GUI display (with the CMakeCache.txt result
completely unaffected), I think that rendering failure in that Motif
corner case would be completely acceptable.  Of course, CTL rendering
failure is a more serious problem if it occurs for any of the majority
platforms (i.e., Linux GTK+, Windows, or Mac OS X). However, I am
pretty sure that CTL should be well supported by IUP on each of those
3 platforms, and if you can confirm that it should be sufficient to
put this CTL support question for IUP immediately to rest.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________