Re: Amaya 0.8a BUGs: German umlauts always uppercase et al.

I have a problem with Amaya 2.4 on Solaris 2.6: 

The characters åäö, ÅÄÖ (a, o with ring or dots over them) are always 
GENERATED in their uppercased form, although Amaya displays them right when
browsing a document generated by some other editor.

It works fine with Amaya 2.4 on Linux RedHat 6.0.
The problem seems to be the same as for Amaya 0.8a, as quoted below.

Is there a workaround for me as a user?


Re: Amaya 0.8a BUGs: German umlauts always uppercase et al.

From: Mark Seb. Fischer (fischer@manati.horz.technopark.gmd.de)
Date: Wed, Sep 04 1996 
>     >> - - German umlaut characters are always GENERATED in their
>     >> uppercased form, although Amaya displays them right when
>     >> browsing a document generated by some other editor.
> 
>     DV>   I have just tried to generate them again, and it seems to
>     DV> work !
> 
>     DV> I have generated lowercase A umlaut by doing :
> 
>     DV> pressing and releasing the <Alt> modifier pressing and
>     DV> releasing the <A> key pressing and releasing the <"> (double
>     DV> quote) key
> 
>     DV> For the capital one :
> 
>     DV> pressing and releasing the <Alt> modifier pressing the <Shift>
>     DV> modifier pressing and releasing the <A> key releasing the
>     DV> <Shift> modifier pressing and releasing the <"> (double quote)
>     DV> key
> 
>     DV>   Could you check these sequences. Was the umlaut mapped to
>     DV> another char on your keyboard (like a diacritic) ? I have
>     DV> copied the sequences available from the X11R6 Compose file :
> 
>     DV>       /usr/X11R6/lib/X11/locale/iso8859-1/Compose
> 
> As I am german, I have a keyboard, wich has the german umlauts as
> normal keys on it (keys nos. 0x30 ('ä', &auml;), 0x2f ('ö', &ouml;),
> 0x22 ('ü', &uuml;) and 0x14 ('ß', &szlig;). I use the standard
> ~/.Xmodmap that came with my (german) Linux Distribution, and these
> are the relevant portions of the output from xkeycaps:
> 
>         !
>         ! This is an `xmodmap' input file for PC 102 key keyboard #1 (Linux/XFre>e86 German layout) keyboards.
>         ! Automatically generated on Wed Sep  4 13:48:17 1996 by fischer with
>         ! XKeyCaps 2.29; Copyright (c) 1995 Jamie Zawinski <jwz@netscape.com>.
>         !
>         ! This file makes the following changes:
>         !
>         ! The "§ 3 ³" key generates 3, paragraph, and threesuperior
>         ! The "K" key generates k, K, and Arabic_kaf
>         ! The "L" key generates l, L, Arabic_lam, and Greek_lamda
>         ! The "Alt Gr" key generates Mode_switch, and the Mod3 modifier
>         >
>         keycode 0x14 =  ssharp          question        backslash
>         keycode 0x22 =  Udiaeresis
>         keycode 0x2F =  Odiaeresis
>         keycode 0x30 =  Adiaeresis
>         keycode 0x26 =  A
>         keycode 0x3C =  period          colon
>         >
> XEmacs, eg. always worked fine for me, treating Udiaeresis like any
> other "normal" key (like 'A' above, wich is menitioned only
> uppercase), getting a "udiaeresis" when pressed without the "Shift"
> key, and a "Udiaeresis" when pressed with "Shift" (to be looked at
> with "M-x view-lossage").
> 
> When I changed my Xmodmap to have different entries for lower and
> upper (like the period / colon pair above), I could work with amaya:
> 
>         keycode 0x22 =  udiaeresis      Udiaeresis
>         keycode 0x2F =  odiaeresis      Odiaeresis
>         keycode 0x30 =  adiaeresis      Adiaeresis
>         >
> So my conclusion is that maybe amaya doesn't respect environment
> variables LC_CTYPE (or LC_ALL, cf. locale(7)), which I have set to
> iso_8859_1 (I also tried de_DE.ISO8859-1 and ISO-8859-1 (this is the
> one referenced in the locale(7) man- page)) and regards Udiaeresis not
> to be a normal character and thus takes it verbatim instead of
> applying case-conversion according to the "Shift" Key.
> 
> from isalpha(3):
> 
>        isalpha()
>               checks for an alphabetic character; it  is  equiva-
>               lent to (isupper(c) || islower(c)).
>         [...]
>        The details of what characters  belong  into  which  class
>        depend on the current locale.  For example, isupper() will
>        not recognize an A - umlaut as an uppercase letter in  the
>        default C locale.
> 
> Hope this may help you and/or others.
> 



-- 
Helge Stenström             
Ericsson Radio Systems AB: KI/ERA/X/FE
e-mail: helge.stenstrom@era.ericsson.se    phone:  +46-8- 404 2323

Received on Tuesday, 29 February 2000 03:24:28 UTC