----------------------------Original message----------------------------
Glenn comments on Keld:
 
>   >In Europe  it is common practice to input special characters
>   >by name in several word processors, like TeX, SGML, troff; in
>   >Wordperfect you do it by character code, and secretaries do this.
>   >In WordPerfect you can also input characters by name, like
>   >"alpha", "beta" etc, in formulae. But maybe you are not informed on
>   >European practice?
 
>I happen to think this practice is hopelessly outdated.  A modern system
>should provide virtual keyboards and multiple input methods that allow the
>user to enter character data without recourse to knowing the names of
>characters, i.e., by having key mappings to the desired characters, by
>employing appropriate key(s) -> composite character sequence mappings, or by
>employing the necessary language representation conversion as needed to
>enter Han characters.
 
I agree with Glenn, but let's face it, we just don't have the hardware.
About 10 years ago I saw a demo keyboard from (I think) Anderson-Jacobsen
which has LEDs in each keycap, and as you got the host to send escape
sequences to the terminal, to change alphabet, the keycaps lit up with
the right symbols. It wouldn't be *that* expensive to do, perhaps make a
keyboard cost $200 instead of $100. Fixing the characters shown on the
screen is (by now) trivial, except that very little software actually
does it right. I for one would love to go back to my first keyboard layout,
used on LinoType hotmetal composing machines, because it was ergonomic,
but that's fantasy because the physical design was different.
 
So while we wait for the world to wake up, what do we do? As Keld says, we
carry on using name-sequences because it's comprehensible, even though it's
more keystrokes, or using (re-using or even mis-using?) control characters
or characters from 128d thru 255d as in many wordprocessors.
 
Some pragmatic fixes:
 
We use PC-Write a lot on campus. It's a bit middle-of-the-road, and not a
graphical WP system, but it's robust, cheap and easy to use. Diacriticals
are entered by pressing the letter, the grave-accent, and then the accent
character, so an á goes in as an "a", a "`" and a "'". The grave
accent key causes a cursor-left movement over the letter, and when the
accent character is typed, the screen character changes to the requisite
diacritical. There's a set of keystrokes like this to enter all the IBM PC
code page 437 and 850 non-ASCII characters. It's OK, faster than Alt-x-y-z
and in any case PC-Write can define keyboard keys to generate any character you
want, if you really need to emulate QWERTZ or AZERTY or anything else (altho
you still have to stick paper on the keycaps to show what's what).
 
Why am I saying this? Well, we also use TeX and SGML, so we can use this
reprogramming capability (and most four-wheel WP and DTP should be able to
do this) to let the user have single keystrokes, but generate the required
characters in the file. Nothing special here, lots of folks do it. But one
of the "hidden" reasons we pressed for PC-Write is that you can also reprogram
the print drivers (which are actually character-conversion specs in a plain
editable text file) to output whatever you want when you print-to-disk. So
a user can have arbitrary IBM PC characters in a file so that the text looks
right on the screen, but if they print to disk, they get a file full of TeX
or SGML. Not only that, but so long as they stick to a specific filetype
it's transparent to them (.doc will output .tex and .iso will output .sgm)
because the print driver can be made sensitive to the input filetype and use
the correct definitions. You want SGML instead of TeX? rename the file from
mythesis.doc to mythesis.iso and print to disk again. And if you don't want
TeX or SGML, you still have a valid PC-Write file for plain WP purposes.
 
In any case, TeX v3 is 8--bit, so you can put a (say) IBM PC character 160d
(á) in your input file and use \catcode`\x=\active\defx{\'a} in your
macro file (where `x' is actually a 160d, omitted here to honor email
restrictions) and TeX will quite happily print an a-acute.
 
I'm sorry if this sounds like a plug, it's not meant to be, just that we saw
this one coming years ago and tackled it head-on. A skeleton version of this
stuff is in PCWRITEX.ARC (or .ZIP) in SIMTEL-20 and a variety of other
archives, if you want to look at it.
 
OK, so it's not perfect. It's restricted to the crappy and proprietary IBM
PC character set, and PC-Write is a visual WP, not a logical one, so it has
no clue about structure, making it silly to use this and expect to get
structured LaTeX or valid SGML out of it, all it's doing is mapping characters.
But it sure as hell takes the pain out of *my* job, when students come up
with a file, suddenly having decided they want to use TeX instead of WP.
 
NOW...who's going to genericise this kind of process so it will (a) work with
an arbitrary character set (ISO or otherwise); (b) work in a sensible graphical
mode (inside MS-Windows, X-Windows etc); (c) run on something other than DOS;
and (d) be publicly available?
 
The source code of PC-Write is available from the authors, but there are
other, probably much better, editors also available. The alternative is to
shell out $6000 for a copy of Arbortext's SGML/edit (no TEI discount) or
use SoftQuad's Author/Editor (our choice for the future), or one of the other
offerings: and they all have their drawbacks, including an assumption that
the user (often a WP-oriented student, staff or faculty member) has a sound
working knowledge of SGML.
 
Ah, I hear you say: wait for WordPerfect's SGML version. Hehehe. Much as I
hate to plug WordPerfect (IMHO *the* antithesis of ergonomic editing), if
we all take it on board, and publicly praise it, Microsoft _et al_ will not
be far behind giving SGML compatibility to their competing products (actually
I was under the impression that Word already had some form of SGML s
sensitivity). Then perhaps we will be on the right road, but we still have
the major hurdle to overcome: getting users to think structured rather than
think visual, until the software becomes capable of divining (or asking for)
*why* the user has switched to boldface, or has entered an isolated line
beginning with a digit and a period :-)
 
Sorry for the ramble...
 
///Peter