[developers] [spr30362] bug using climxm

[Berthold Crysmann]

Berthold Crysmann wrote:
> Andreas Fuchs wrote:
>> Hello Berthold,
>>
>> On Sep 22, 2006, at 14:50, Berthold Crysmann wrote:
>>> Andreas Fuchs wrote:
>>>> This patch outputs a bit of debug information when going through
>>>> the locale possibilities on application startup.
>>>>
>>>> There is one important thing to note, though: Due to an XT limitation,
>>>> the application must set or bind excl:*locale* to the correct value
>>>> before the first application frame is created and the port is
>>>> initialized.
>>>>
>>>> Regards, Andreas.
>>>>
>>> Dear ,
>>>
>>> I have tried this new patch but, unfortunately, the behaviour has 
>>> not changed (apart from an error message).
>>> This is what I did:
>>>
>>> Start clim with C.UTF-8 locale
>>>
>>> /usr/local/acl80/bclim -locale C.UTF-8
>>
>> I forgot to include one warning about excl:*locale*: due to Motif 
>> using the libc's locale definition, excl:*locale* must be bound to a 
>> locale that both allegro cl and the libc understand. From the 
>> behavior you reported below, it looks like the libc doesn't 
>> understand that C.UTF-8 means it should use utf-8 encoded characters. 
>> (that's why you get the error: allegro cl expects a utf-8 encoded 
>> string, but gets a latin-1 one).
>>
>> I tested with de_AT.UTF-8 on debian gnu/linux. If you have utf-8 
>> locale definitions for your current locale (I'm assuming that's de_DE),
> Hi Andreas,
>
> thanks for your mail.
>
> Actually, my standard locale is en_GB.UTF-8. I have tried that now --- 
> with partial success.
>
0. Opening the input widget for the first time, I get the following  
error message:

 Warning: Missing charsets: ISO10646-1, GB2312.1980-0, KSC5601.1987-0,
         creating fontset for
         
-alias-fixed-medium-r-normal--10-100-75-75-c-50-jisx0201.1976-0,-alias-fixed-medium-r-normal--10-100-75-75-c-100-jisx0208.1983-0,-adobe-helvetica-medium-r-normal--8-80-75-75-p-46-iso8859-1,



> 1. If I paste my German umlauts into the input widget with the mouse, 
> I get:
>
> Warning: Xt:
>    Name: xmTextField
>    Class: XmTextField
>    Character '\344' not supported in font.  Discarded.
>
> Still the "ä"  is  part of the input and the Umlaut shows up correctly 
> in the output. In the input window, the Umlaut is not displayed.
>
> 2. If I try to insert the umlaut with the keyboard (Compose+"+a), I 
> get a slightly different behaviour:
>
> Error message is the same and the umlaut character is not displayed. 
> It also gets inserted into the input string. Subsequent characters, 
> however, are inserted to its left ("Er schläft" yields "Er schlftä"). 
> It is possible to fool the system by entering all non-umlauts first, 
> and  then insert the umlaut.  
> I hope that helps narrowing down the problem.
>
> Best wishes,
>
> Berthold
>
>> I suggest you use that and append .UTF-8 to get de_DE.UTF-8.
>>
>> I'll try to come up with a test for acl&libc locale compatibility, 
>> but for now, I hope the above will work for you.
>>
>> [cut]
>>> Opening the relevant input widget (Parse input ...) I tried to enter 
>>> a simple German sentence "Er schläft."
>>>
>>> Problem 1: Keyboard input of "ä" (Compose+"+a) did not work at all 
>>> (nothing inserted). (I checked this "adding" trailing Umlauts to 
>>> other words.)
>>> Problem 2: Pasting the string with the mouse (button 2) Only shows 
>>> the characters to the left of the umlaut in the input widget and an 
>>> error message:
>>>
>>> "
>>> Error: Error reading mb-vector from
>>>         #<EXCL:BUFFER-INPUT-SIMPLE-STREAM pos 7 @ #x6daf746a>
>>> "
>>>
>>> Best,
>>>
>>> Berthold Crysmann
>>
>> Thanks,
>> Andreas.
>>
>