🚀 go-pugleaf

Gee, I managed to prompt quite a bit of discussion from "names" in the
field.  'Cept Greg.  THWACK!  ... Sorry Greg ;-)

In article <1991May9.000730.23509@mtxinu.COM> jaap@mtxinu.COM (Jaap Akkerhuis) writes:

(thanks again for that document Jaap)

>First some background:

>Someone complained that vertical lines came out slanted in eqn when he
>wasn't expecting it.

>In article <1991May6.152022.28260@cbnewsl.att.com> npn@cbnewsl.att.com (nils-peter.nelson) writes:
> > ... Brian Kernighan (author of pic) insists
> > italic applies to letters only; X persistently slants

Letters only?  What about digits?

> > *all* characters in the Italic fonts. Brian says he may
> > try to change pic not to assume Italic is safe for
                  ^^^ you mean eqn here right?
> > non-letters, but no promises.
> > I had to put shameful fudges in to get square roots,
> > table corners and brackets to align, because of
> > similar disagreements between X, PostScriptt and troff.

These "shameful" fudges are a fact of life - not every font
has the design considerations of connecting some of the pieces
together as troff is assuming.  Psroff, in addition to the mapping
information, also has arbitrary X and Y shifts and scaling associated
with each emittable character.  Most times these are 0, 0 and 1, but
there are a number of non-default ones.  In Laserjet output,
psroff has quite a number of shifts to get things to lineup.  In Postscript
there's only a couple because the box drawing characters aren't taken from
the built-in fonts, they're a font that gets downloaded in each run
and have been designed for the purpose of troff (borrowed from tpscript).
As are the big brace parts, \(br and \(ru.  HP Laserjet would be even
worse than it is, but again, the special bracket parts were specially
built for the purpose (borrowed with permission from Jetroff)

>Remember good old troff? Just four fonts with very limited amount
>of characters.  So basically old the special characters were taken
>from the special fonts.

"|" is in the normal font in CAT Troff, and the old eqn is asking for
it in the italic font.  Which, in Postscript, means slanted bars.

I think I can summarize a number of points here:
    1) eqn has a bug in that it is requesting "|" instead of \(br in this
       context.  \(br is in the Symbol font in both CAT troff and probably
       most ditroff's width tables.  \(br would make more sense in the
       context of eqn requesting vertical lines.
       It gets big square brackets right, why not this?
       All eqn's seem to request "|" rather than \(br, but only certain
       eqn's make the mistake in (2) that makes it noticable.
       "|" is a character, NOT a line drawing "part".
    2) eqn should be robust in the face of "font 2's" slanting
       more than just alphanumerics.  So, if it has to ask for "|"
       it *should* ask for it in font 1.  It does it for parenthesis,
       so why not "|"?
    3) I'm not sure whether I agree with Brian (that only alphanumerics
       should be slanted in an Italic font), but eqn shouldn't insist
       on it either.  If you go by Brian's insistance, then you lose a lot
       of potentially useful glyphs.  I'd prefer everything slanted - so
       that if you mix alphanumerics with characters such as [, ], {, }
       etc that they don't stand out - they appear equally altered.
       I've seen lots of published troff documentation that had slanted
       "|" in italic.  (Sun for example)
    4) I could have psroff always emit \(br's code (special font), but that
       character is somewhat longer and its weight is constant, which would
       make it standout in many fonts.
    5) If I get psroff to always request Times-Roman for "|", it still wouldn't
       change "face" with .ft's or .fp's.

If I did (4) or (5) a "|" in any font would occupy the space specified
for that font, but it would have varying amounts of surrounding white-space,
and its weight wouldn't match some fonts.  Ie: this:
	hello|hello
would look like (exaggerating the separation) in a "wider font":
	h e l l o |   h e l l o
(Ie: the troff would respect the width specifications, but the backend
would emit the same character no matter what font it was in)

Since there isn't a clear "correct" way to do this without buggering
with eqn source (which isn't available to most psroff users anyways) or
buggering up output in one way or the other, I think I'm going to leave it
as is, with instructions on how to "fix" it in the psroff run-time parameter-
ization files if it becomes a problem with eqn output.

Thank you all.
-- 
Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca
UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List:
ferret-request@eci386; Psroff (not Adobe Transcript) enquiries:
psroff-request@eci386 or Canada 416-832-0541.  Psroff 3.0 in c.s.u soon!