clewis@ferret.ocunix.on.ca (Chris Lewis) (05/06/91)
A psroff user writes: | .EQ | left nothing {d f(x)} over {d x} right | | .EN | I get | | df(x) / | ----- / | dx / Eqn emits: | .EQ | .nr 99 \n(.s | .nr 98 \n(.f | .ps 10 | .ft 2 | .ds 11 "d | .ds 12 "\^f\|\|\f1(\fPx\|\f1)\fP | .as 11 "\*(12 | .ds 12 "d | .ds 13 "x | .as 12 "\*(13 | .nr 11 \w'\s10\*(11' | .nr 12 \w'\s10\*(12' | .nr 13 \n(11 | .if \n(12>\n(13 .nr 13 \n(12 | .nr 13 \n(13+\s10.5m\s0 | .ds 11 \v'42u'\h'\n(13u-\n(12u/2u'\*(12\ | \h'-\n(12u-\n(11u/2u'\v'-78u'\*(11\ | \h'-\n(13u-\n(11u/2u+.1m'\v'18u'\l'\n(13u-.2m'\h'.1m'\v'18u' | .ds 11 \|\v'-3u'\v'3u'\*(11\|\v'-3u'\b'|||'\v'3u' ^^^^^^^ | .ds 11 \x'0'\x'0-45u'\f2\s10\*(11\s\n(99\f\n(98\x'51u' | .nr 11 \w'\*(11' | .nr MK 0 | .if 180>\n(.v .ne 180u | .rn 11 10 | \*(10 | .ps \n(99 | .ft \n(98 | .EN By my reckoning, the "pile" of "|" is in font 2 (Italic). Psroff agrees, and emits a request for the "|" character in the Times-Italic font which is slanted (in Postscript). To me this looks like a bug in eqn. On the other hand, pscat seems to emit vertical "|" in this example. I'm not sure whether pscat thinks it's in font 1 or 2, or whether this is special cased. I can fix this in psroff simply enough (have *all* "|" come out in Times-Roman), but this doesn't seem quite right to me. Any idears?
npn@cbnewsl.att.com (nils-peter.nelson) (05/06/91)
In fixing up xditview, this was the one "bug" I couldn't solve. eqn | troff | xtv will display piles with slanted lines. Brian Kernighan (author of pic) insists italic applies to letters only; X persistently slants *all* characters in the Italic fonts. Brian says he may try to change pic not to assume Italic is safe for 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.
zvr@ntua.gr (Alexios Zavras) (05/08/91)
In article <1991May6.152022.28260@cbnewsl.att.com>, npn@cbnewsl.att.com (nils-peter.nelson) writes: > In fixing up xditview, this was the one "bug" I couldn't > solve. eqn | troff | xtv will display piles with > slanted lines. Brian Kernighan (author of pic) insists > italic applies to letters only; X persistently slants > *all* characters in the Italic fonts. I don't know about xditview (never bothered using it), but xproof displays the `|' straight (not slanted) ! Of course, this might be the X font it uses... By the way, psdit emits Postscript that uses the *Symbol* font and its `|' character to draw the line... -- zvr -- +---------------------------+ Alexios Zavras (-zvr-) | H eytyxia den exei enoxes | zvr@ntua.gr +-----------------------zvr-+ zvr@theseas.ntua.gr Somebody said it couldn't be done / But he with a chuckle replied, Maybe it couldn't, but he would be one / Who never said no till he tried. So he buckled right in / With a brace and a grin And if he was worried, he hid it, He started to sing / As he tackled the thing That couldn't be done And he did it.
rcd@ico.isc.com (Dick Dunn) (05/09/91)
clewis@ferret.ocunix.on.ca (Chris Lewis) writes: [eqn example with | ] > By my reckoning, the "pile" of "|" is in font 2 (Italic). Psroff agrees... ... > ...On the other hand, pscat seems to > emit vertical "|" in this example. I'm not sure whether pscat thinks > it's in font 1 or 2, or whether this is special cased. If by "pscat" you mean the TranScript one (just to be sure), this was the subject of a bug fix some time ago; yes, it's a special case. I would say the situation is confused, at best: - TranScript (pscat and psdit) used to let the | character come through in the current font. This gave slanted bars if you were in italic. - After the "fix" (change), the vertical bar was effectively removed from regular fonts so that it would be picked up from the Symbol font. This gives upright bars throughout, but... - Now a constant-width font gets a bar of the wrong width! The bar from Symbol is too narrow, and cruftroff input that counts on lining up constant-width text fails. > I can fix this in psroff simply enough (have *all* "|" come out > in Times-Roman), but this doesn't seem quite right to me. This will give you the constant-width problem I mention. But that can be solved also. Seems to me the problem is in the interpretation of the "bar" character. I don't believe the character produced as a result of the ASCII | (0174, 0x7c) should ever be slanted. The name of the ASCII character is "verti- cal line", and it just doesn't seem like "vertical" should mean "possibly slanted"! If I had to assign blame, I'd assign it to the PostScript fonts which encode a slanted character into that position...but that doesn't do any good, 'cause it's done. What little I can find on troff font examples shows the vertical bar as vertical even in an italic font...so I'd fix it to make 0x7c always produce a true vertical line of appropriate width. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...If you plant ice, you're gonna harvest wind.
woods@eci386.uucp (Greg A. Woods) (05/09/91)
In article <1991May6.152022.28260@cbnewsl.att.com> npn@cbnewsl.att.com (nils-peter.nelson) writes: > In fixing up xditview, this was the one "bug" I couldn't > solve. eqn | troff | xtv will display piles with > slanted lines. Brian Kernighan (author of pic) insists > italic applies to letters only; X persistently slants > *all* characters in the Italic fonts. Brian says he may > try to change pic not to assume Italic is safe for > non-letters, but no promises. I'd tend to say Brian is right, and someone is using an old eqn. I've been waiting for Chris Lewis to reply, but the question has been nagging me too much. The output Chris submitted in the original posting came from a V7 derived eqn. I tried the same test with DWB-1.0, DWB-2.0, and SQPS-2.9 (derived from DWB-2.0). DWB-1.0 shows the same behaviour Chris noted, with almost the exact same output from eqn. DWB-2.0 shows an entirely different handling of fonts in eqn, much like what Nils-Peter says BWK claims. In addition, output appears correct when processed both by tpscript and xproof (on a DMD). SQPS-2.9 is also correct, and its sqeqn output is also almost identical to that of DWB-2.0. So, my nagging question -- Has DWB-3.1 slipped back to the V7/DWB-1.0 version of eqn? If so, how/why? Does DWB-3.2 fix this? > 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. Ah, the age-old problem of finding symbol characters in your favourite output device that have the same positioning and size as what troff expects. My favourite gripe is that troff (from DWB-2.0) uses \(ru to draw horizontal lines (i.e. \l'1.0i'), instead of whatever drawing mechanism that may be implemented to draw every other line. To top it off, most of the lines in tbl are also drawn with characters. At least sqtroff-2.9 draws horizontal lines with the line drawing mechanism, though sqtbl might still use characters. Of course if you are using some form of PostScript device, or other device that allows custom definition of characters, it's (almost) easy enough to fudge up some special characters to meet troff's specs. BTW, I've almost fixed up the definition of \(br and \(ru in PostScript for tpscript. There's still a very minor positioning problem, and a line-thickness problem, but at least now \(ru looks similar to the other lines. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL
jaap@mtxinu.COM (Jaap Akkerhuis) (05/09/91)
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: > > > In fixing up xditview, this was the one "bug" I couldn't > solve. eqn | troff | xtv will display piles with > slanted lines. Brian Kernighan (author of pic) insists > italic applies to letters only; X persistently slants > *all* characters in the Italic fonts. Brian says he may > try to change pic not to assume Italic is safe for > 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. 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. Eqn was/is relying on this fact. Just switching on the italic font (and silently assume it is on position two) for the bulk of the work and then rely on picking the special characters from the special font. Is is a bug in eqn? Well, I'm not sure. Let us first ask ourself, what a vertical bar actually supposed to be if it is italic? Should it be slanted? I can easely defend that a vertical bar should be a vertical bar whether the font is italic or not. If we want a slanted bar we have the slash character (/) anyway. So the behaviour of eqn is right. The font is wrong. Just get the | mapping to a slanted line out of the font descriptions and things will be dandy. Of course, one could be stubborn and argue that, since the italic font slants, the vertical bar should be slanted, just to be orthogonal. Eqn maps the paranthesis to roman when encountered, so it could do the same. However, I can easier see the reason for the paranthesis than a vertical bar. If I want a vertical bar, that is what I want, if I want a slash, I'll ask for it. It looks like I agree with Brian, so I would recommend to go for the first solution. Fix those font description files! Wipe out the definition for the vertical bar! It is amazing how often people take the font description files for granted, without giving it any thought. There is some implied semantics attached to these files. Not only to what makes sense to troff to have in it for a particular font, it also applies to the form of the characters, like how much white there is around the line drawing characters used in \l'' && \L'' requests etc. If the characters don't work properly, fix the font definitions and/or the back-end! jaap PS. I seem to remember that Brian had something to do with eqn as well :-)
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/10/91)
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!
npn@cbnewsl.att.com (nils-peter.nelson) (05/10/91)
Greg Woods suggests that if tbl used line drawing functions we wouldn't have alignment problems in the post-processors. True for troff, but, alas, there are still nroff users around. In fact, since man(1) uses nroff, there's probably more nroff use than troff use. Line drawing is not easy on a tty. Were it not for this we would gladly draw boxes around tables via line drawing. Similar issue for square roots, multi-line brackets in eqn, though I can't imagine there are too many Model 37 Teletype owners using neqn left in the world.
woods@eci386.uucp (Greg A. Woods) (05/15/91)
In article <1991May10.164756.22896@cbnewsl.att.com> npn@cbnewsl.att.com (nils-peter.nelson) writes: > Greg Woods suggests that if tbl used line drawing functions > we wouldn't have alignment problems in the post-processors. > True for troff, but, alas, there are still nroff users around. Ah, but unless my eyes deceive me, nroff knows perfectly well how to draw lines (i.e. horizontal and vertical lines) specified by the line drawing escape seqences (i.e. \l'Nc' and \L'Nc'), even if the character ('c') is not specified. Why could troff not translate this internally into proper draw commands (i.e. \D'l N 0' and \D'l 0 N') when no character is specified? Now if it could, tbl could use \l'' and \L'' to draw it's boxes, and when processed by troff, we'd get the line drawing functions as defined for the given device. In fact, unless my eyes also deceive me, tbl almost does this now, execpt it specifies the character it thinks should be used for line drawing. Of course this is all rather pointless, since the great majority of us will be running either older (DWB-2.0 and previous) troff's (and tbl's), or the Berkely di-troff included in SysVr4.0, and since we don't all have sources, we won't be able to make our troff's (and tbl's) do anything like this. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP ECI and UniForum Canada +1-416-443-1734 [h] +1-416-595-5425 [w] VE3TCP Toronto, Ontario CANADA Political speech and writing are largely the defense of the indefensible-ORWELL