Path: utzoo!telly!eci386!ecicrl!clewis
From: clewis@ecicrl.UUCP (Chris Lewis)
Newsgroups: comp.text
Subject: Re: troff postprocessors for ISO 8859 characters
Message-ID: <1041@ecicrl.UUCP>
Date: 7 Jan 91 04:46:36 GMT
References: <1990Dec28.195703.2749@cbnewsl.att.com> <1038@ecicrl.UUCP> <1991Jan3.151843.24109@cbnewsl.att.com>
Reply-To: clewis@ecicrl.UUCP (Chris Lewis)
Organization: Elegant Communications Inc., Ottawa, Canada
Lines: 63

In article <1991Jan3.151843.24109@cbnewsl.att.com> npn@cbnewsl.att.com (nils-peter.nelson) writes:
|Chris Lewis requests an additional field in the width
|tables to instruct troff how to manufacture the additional
|8859 characters that are not in ASCII. Some of them appear
|quite easy (e.g., the Yen sign looks like a Y with a line
|through it, or the lower case letters with accent marks)
|but others appears near-impossible. For example, all the
|upper case letters will obliterate diacriticals, and the
|Icelandic eth doesn't appear to have an obvious representation.
|Is it worth doing half the job? (I.e., should we try to
|implement those characters that can be done this way and
|forget the others? Do a bad job on the others?)

My suggestion was to permit the fourth field to be more than one
character.  You're quite right in that this seems a bit half-assed,
However, in psroff it's fairly necessary to permit slight adjustment
of some character's placement and kludge up some additional characters.
(Eg: HPLJ box drawing characters don't precisely line up the
way troff expects them to).  Psroff, though, has a somewhat more
sophisticated scheme, in ditroff width table terms it looks like:

	char kern width <sequence> <xshift> <yshift> <scale>

Where <sequence> is a sequence of one or more bytes to emit for the
glyph (it can even be invocations of Postscript functions), x shift and
y shift are adjustment factors that are multiplied by the point size
and added to the X and Y coordinate when positioning the character, and
scale is a facter to apply to the point size. (eg: bullets are too small
in Postscript Roman).  They default to 0, 0 and 1.

In this way, box corners can be tuned etc.  It's not particularly necessary
with Postscript, but it certainly is with Laserjets.

|My inclination is to support two and only two modes for
|"production": PostScript and nroff. If you want ISO 8859
|nroff, get an ISO 8859 terminal. The stuff about 7 bit
|shorthand for 8 bit characters was intended for debugging
|and interchange, not production. So far, no one has answered
|my previous question: will this direction meet the needs
|of the European market?

Speaking unofficially (I'm on the ISO/CSA/Treasury/POSIX committee),
having ditroff accept 8-bit characters on input (also use a reasonable set
of \(sequences for those without the proper terminal), being able to successfully
search for them in the width tables, and emit the appropriate stuff seems
to be consistent (from the perspective of code, not tables) and sufficient
for Canada to be happy (Canadian Federal Govt. is pushing 8859-1 because of
French-English bilinqualism requirements).

From the perspective of only supporting Postscript on troff with 8859-1,
do you have any comments on the suggestions I made?  At the very least,
the other troff filters should *not* disallow 8-bit, and permit extension
of the character set by the user when/if the appropriate fonts are available.
Including the proper tables (and a pointer to where fonts might be obtained)
would be even better if you can't compress the fonts.

I think it would be a drastic mistake to only support 8859-1 on Postscript.
It's not that hard for HPPCL.
-- 
Chris Lewis, Phone: (613) 832-0541
UUCP: uunet!utai!lsuc!ecicrl!clewis
Moderator of the Ferret Mailing List (ferret-request@eci386)
Psroff mailing list (psroff-request@eci386)