Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!agate!garnet.berkeley.edu!csvsj
From: csvsj@garnet.berkeley.edu (Steve Jacobson)
Newsgroups: comp.windows.x
Subject: Entering ISO ASCII characters >= 128 into TextEdit widgets
Keywords: ASCII, TextEdit, translations
Message-ID: <1990Apr11.210847.4588@agate.berkeley.edu>
Date: 11 Apr 90 21:08:47 GMT
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Reply-To: csvsj@garnet.berkeley.edu (Steve Jacobson)
Organization: University of California, Berkeley
Lines: 17

If a complete ISO Latin ASCII font is used, a TextEdit widget can display
correctly strings containing diacritical marks, such as accent marks and
oomlats (sp?). (I use the HP TextEdit widget, but I assume that the Athena
widget is similar.)

When entering data from the keyboard into a textedit widget, default
translations do not allow easy input of ASCII characters above character 127.
The Xt translation mechanism may be used to make diacritic input possible.

I would love to hear from someone who has looked into this problem. It is
reasonable to want the keystroke that will input an 'a' with an attached
diacritic to involve the 'a' key. That there are six different diacritical
sequences involving the 'a' (seven, if you count the character 230, which
looks like an 'a' crammed up with an 'e') only complicate matters. It is
also reasonable to assume that the EMACS control sequences that already
take up much of the translation territory are necessary and should not be
trampled upon.