Path: utzoo!attcan!uunet!munnari!moncskermit!goanna!isaac
From: isaac@goanna.oz (Isaac Balbin)
Newsgroups: comp.text
Subject: Re: inherent troff faults
Message-ID: <1317@goanna.oz>
Date: 9 Jun 88 22:45:25 GMT
References: <1309@goanna.oz> <7562@boring.cwi.nl>
Reply-To: isaac@goanna.oz (Isaac Balbin)
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 19

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?