[M3devel] Fwd: Re: Fw: UTF-16: Greek alphabet with CM3

Elmar Stellnberger estellnb at elstel.org
Sun Dec 1 20:37:28 CET 2013

Am 01.12.2013 18:15, schrieb Rodney M. Bates:
> On 12/01/2013 02:47 AM, Elmar Stellnberger wrote:
>> Am 30.11.2013 17:02, schrieb Rodney M. Bates:
>>> The en/decoders are available in one-code-point-per-call forms, as well
>>> as in filters that are semantically almost identical to Wr and Rd, 
>>> which
>>> work on whole streams, with a constant encoding.  The latter, in 
>>> front of
>>> TextWr/TextRd would probably make it easy to interface to any GUI 
>>> library
>>> that uses in-memory UTF-8, etc.
>>> It also would not be hard to make these work with 16-bit WIDECHAR, with
>>> any input coded beyond UFFFF converted to the standard Unicode 
>>> replacement
>>> UFFFD.  It sounds like you would be unlikely to use such values.
>> Yes, for that project I just need letters up to 0xFFFF i.e. latin-1 
>> and -7.
>> Currently I have copied a keyboard translation into 
>> /usr/share/X11/xkb/symbols/
>> that will give me greek chracters on [AltGr][Letter]. Nonetheless the 
>> current
>> Windows implementation of the simulator suffices without such a trick 
>> because
>> it can intercept the [AltGr] keystrokes. I have not evaluated yet 
>> whether the
>> current VBT input form would allow a similar mechanism.
>>> How soon do you need to start?
>> It would be good if that was available until January so that I can 
>> approach to
>> finish my work until February. Fortunately there is some work which I 
>> could
>> do in advance at least if the interfaces should not change radically. 
>> At least
>> I should have some result at the beginning of March.
> Enough of what the Unicode branch could do for you has been working 
> for some time.
> The remaining problems are convenience/packaging things, testing of 
> big-endian and
> mixed-endian pickles and network objects, and bootstrapping.  I have 
> not rebootstrapped
> using the release compiler in a couple of months, but I believe there 
> are some new
> bootstrap barriers that have popped up.  Also, the only backend that 
> is done is
> the gcc-4.7-derived one, although I think that will cover the majority 
> of the targets.
> What target are you using?
AMD64_LINUX, LINUXLIBC6. However the program will need to work on 
windows as well.
> As for what GUI system to use, that is another question, but the 
> Unicode branch
> would allow you to pass/receive strings in any of the encodings, yet 
> process
> them in M3 code as simple characters, without having to mess with or 
> understand
> the encodings.  That should pretty well open up all your options on 
> what GUI
> system to use.  Also, it would make late changing to a different 
> encoding trivial.
Yes, I should likely check that branch out and compile it.
However for the final program a stable version of it will be absolutely 
Then I will also have to decide whether I can use Trestle/vbtkit or 
whether I should try to
convert a current GTK with swig.


More information about the M3devel mailing list