Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!att!cbfsb!cbnewsc!cbnews!cbnewsm!cbnewsl!npn
From: npn@cbnewsl.att.com (nils-peter.nelson)
Newsgroups: comp.text
Subject: International (8 bit clean) troff proposal
Keywords: dwb, troff
Message-ID: <1990Dec27.155046.14520@cbnewsl.att.com>
Date: 27 Dec 90 15:50:46 GMT
Organization: AT&T Bell Laboratories
Lines: 38


Thanks to all those who responded to my request for international
troff requirements.  The responses were uniformly helpful and
specific (if occasionally impatient with the backwardness
evident in this little part of the world).  In addition to public
responses, I got private letters from: Anders Thulin, Dan Berry,
Dick Dunn, Heimir Thor Sverrisson, Chris Lewis, Alexios Zavras,
Jaap, Robert Andersson, Steve Azmier, and a very appropriate paper
from Keizer, Simonsen and Akkerhuis [KSA].

The consensus appears to be:
1. Allow all DWB components to read 8-bit characters as defined
by ISO 8859-1, a.k.a Latin-1.  The editing and preparation of
such documents is the province of 8-bit terminals, 8-bit editors,
and not our concern.  This requires that we remove all &177's.
2. Default behavior for troff should be "8-bit in, 8-bit out".
The postprocessors will be rewritten to take this into account.
In addition, we should allow a "-7b" option to force troff
output to be in the ASCII (ISO 646, 7 bit) subset.  This would permit
mailing of ditroff output to the part of North America that
hasn't caught on to ISO 8859.
3. Recognize two-character 7-bit escapes so that people who
don't have 8-bit terminals can still create documents with
the extra characters,  [KSA] have proposed a reasonable standard
convention which could serve as both input and output for troff.
(e.g., \(oa for 'aring') but there are other proposals we
will look at as well.
4. Reserve \C'string' and \N'number' for the truly odd characters
that don't have a more convenient representation.
5. Hyphenation may present insurmountable problems; we'll see
if anyone else (e.g. Knuth) has solved them.  Worst case,
however, is that we'll hyphenate badly, and you'll have to
turn it off.

We will probably package this as DWB 3.2, which will be an
"incremental" upgrade to DWB 3.1 (this means a minor fee for
those who are DWB 3.1 licensees). Some of the work has already
been completed, so the package should be ready around May 1991.