isaac@goanna.oz (Isaac Balbin) (06/02/88)
I am/have been a troff (-me) user for years. All this TeX talk and WYSIWYG talk makes you take notice every now and again. However, you are so entrenched, and like the terse but powerful syntax that you defer any change. I will still probably do that. On the other hand, every now and again you get an annoying re-occurrence of the dreaded environment stack problem with troff that rears its ugly head. Consider my experience today. A simple .sh 2 "The $call$ function" the $'s are my eqn delimiters. Why put call in $'s? simply because I use it and other variables/formulas throughout in a different font and I have a global font of CW (for you postscript types) for eqn symbols. So what was the output? The came out in bold font as I would expect call came out in CW font as I would expect function came out in roman! font unexpectedly. I expected bold, wouldn't you? It didn't appear to stack the fonts properly when popping them. I haven't thought about the "why" too much and this is my guess ... I could be wrong, but that is irrelevant. Then in the same paper, on one page, the date at the bottom just disappeared mysteriously. I never use a .hl inside keeps because they come out really screwy - too long, too short or dashed lines. This one is an environment problem (.ev) too. The bottom line is that there are companies that distribute so called debugged/improved versions of (di)troff. Do they knowingly distribute buggy code, or have they fixed these things? I once heard from an unnamed very well known guru that these things can be fixed, but then lots of documentation would be broken. I am not convinced by this argument at all. Well, do we fix troff or go to TeX quite apart from any philosphical reasons?
aeb@cwi.nl (Andries Brouwer) (06/06/88)
In article <1309@goanna.oz> isaac@goanna.oz (Isaac Balbin) writes:
! Consider my experience today. A simple
! .sh 2 "The $call$ function"
!
! the $'s are my eqn delimiters.
! So what was the output?
! The came out in bold font as I would expect
! call came out in CW font as I would expect
! function came out in roman! font unexpectedly.
!
! I expected bold, wouldn't you?
That depends. Certain antique versions of eqn save the font
*** at the beginning of the input line ***
and after meeting the closing delimiter, restore that font.
--
Andries Brouwer -- CWI, Amsterdam -- uunet!mcvax!aeb -- aeb@cwi.nlisaac@goanna.oz (Isaac Balbin) (06/10/88)
In article <7562@boring.cwi.nl> aeb@cwi.nl (Andries Brouwer) writes:
!
! That depends. Certain antique versions of eqn save the font
! *** at the beginning of the input line ***
! and after meeting the closing delimiter, restore that font.
!
That sort of semantics is wrong because it is not the intuitive
semantics of the construct.
.sh 2 "The $call$ procedure"
says write out the string as a sub heading
in the sub heading font. One section of the string is $call$.
Of course, where the eqn font is different from the sub-heading font,
(the same goes for size) then since eqn is a *pre*-processor we
expect that call should have a sort of \fP to return to the current environment.
Your reply suggests that eqn considers the current environment to be the one
immediately *before* the .sh .... is this logical, sane? Is integration
a real fault of troff families of products? Can you, for example,
effectively put eqn stuff into pic and always have it look right?
Which version of eqn are you using which doesn't? cause this, dwb2.0?eggert@sm.unisys.com (Paul Eggert) (06/12/88)
In article <1309@goanna.oz> isaac@goanna.oz (Isaac Balbin) writes that given .EQ gfont C .EN .sh 2 "The $call$ function" his (eqn | ditroff -me) formatter prints "function" in roman, not bold as it should. This may arise from a common problem: in some buggy ditroffs, \fP doesn't work if you're switching among fonts not mounted by default. A workaround is to place a directive like .fp 4 C at the start of the input, substituting some unused font number for `4'. This will permanently mount font C, dodging the bug. Balbin also writes: I once heard from an unnamed very well known guru that these things can be fixed, but then lots of documentation would be broken. The bug I've described has been fixed in our ditroff, and it doesn't break any documentation. Perhaps the guru was referring to the fact that \fX...\fP doesn't nest, but this doesn't seem to be the problem here.
isaac@goanna.oz (Isaac Balbin) (06/16/88)
Sorry Andries.
In article <rr|*i34@sea.sm.unisys.com> eggert@sm.unisys.com (Paul Eggert) writes:
! This may arise from a common problem: in some buggy ditroffs, \fP
! doesn't work if you're switching among fonts not mounted by default.
! A workaround is to place a directive like
!
! .fp 4 C
!
! at the start of the input, substituting some unused font number for `4'.
! This will permanently mount font C, dodging the bug.
!
Ahhh this explains something else I saw yesterday.
Until now I was using an explicit .ft CW inside my .(l .(b .(z
to make sure that the output in keeps (-me style) was in CW font.
I noticed I also had a .nr df 7 which is supposed to set the font
inside keeps to font number 7 == CW for me. I then wondered, why do I then
also *explicitly* say .fT CW (you see you do these things and forget why you
did them). I chased it all the way to the .@F macro in tmac.e.
This macro is used to control the font inside keeps.
Here is the macro.
.de @F
.nr ~ \\$1
.if \\n~>0 \
\{\
. ul 0
. if \\n~>4 \ *****************************
. nr ~ \\n($b
. ft \\n~
.\}
.rr ~
..
This code explicitly stop you from using any fonts mounted after 4.
I wondered why. Indeed, I replaced the macro without the test.
However, in light of what Paul just said, this magical feature might
just be neceesary for "buggy" ditroffs (is there any other type?).