Path: utzoo!utgpu!cunews!micor!latour!ecicrl!clewis From: clewis@ferret.ocunix.on.ca (Chris Lewis) Newsgroups: comp.text Subject: Re: In troff, is "|" supposed to be slanted in Italic? Message-ID: <1481@ecicrl.ocunix.on.ca> Date: 10 May 91 03:59:44 GMT References: <1470@ecicrl.ocunix.on.ca> <1991May6.152022.28260@cbnewsl.att.com> <1991May9.000730.23509@mtxinu.COM> Organization: Elegant Communications Inc., Ottawa, Canada Lines: 95 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!