groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

heirloom eqn (was: [Groff] OTF in Groff or -mom in Heitrloom troff...)


From: Joerg van den Hoff
Subject: heirloom eqn (was: [Groff] OTF in Groff or -mom in Heitrloom troff...)
Date: Fri, 11 Jan 2008 13:00:23 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Thu, Jan 10, 2008 at 09:57:18PM +0100, Gunnar Ritter wrote:
> Joerg van den Hoff <address@hidden> wrote:
> 
> > shows  that  the "hat" is sort of right aligned above the K,
> > not centered as the dot is in the ps  output.  moreover  the
> > vertical distance above the K seems different for both marks
> > (probably they both are "top aligned" in this direction?).
> 
> Thanks. A fix is in the CVS repository.
> 
> > what's  more:  the  default  spacing used by `eqn' (i.e. the
> > spacing used without introducing explicit white space,  e.g.
> > with  the  `^'  command) is markedly different between groff
> > and "htroff"    eqn.  in  htroff  there  seems  actually  no
> > additional  white  space  whatever  in  the above equations,
> > e.g.. this simply does not look right. I confess not  having
> > thoroughly   looked   whether   this  spacing  is  somewhere
> > adjustable via registers (maybe  it  is),  but  if  so,  the
> > default value at least is not a good one.
> 
> It seems that this has been a deliberate decision with the
> original eqn since its user's guide explicitly states that
> you should use "~" to get more space with equations. When
> this document is formatted with geqn, the output looks the
> same with and without the "~", so the remark would make no
> sense with it.

I don't think so. look at 

http://cm.bell-labs.com/cm/cs/papers.html

where  there is a ps version of the original eqn users guide
(first entry in the list). the postscript  header  indicates
that  this  was generated by some `dpost' implementation. if
you look, e.g.  at the small equation (3.1a) on  the  second
page  and  write  this  down  without any explicit space and
alternatively with explicit spaces:

.EQ
lpile {
x = f(y/2) + y/2
above
x ~ = ~ f(y/2) ~ + ~ y ~ / ~ 2
}
.EN

and  compare  "geqn/groff"  with  "heqn/htroff" generated ps
output _and_ with the above document from bell  labs  you'll
see  especially  that  in  the  original doc the equation is
typeset with _some_ spacing, different from groff  but  more
(and better) spacing than by heqn/htroff.

> 
> In general, geqn goes more into the direction of TeX and
> tries to more automatically layout the formulas, whereas
> the old eqn on which Heirloom eqn is based requires manual
> interaction in many places. However, documents on which
> such hand-tuning is applied would not get formatted as
> intended if Heirloom eqn did the same. Thus, I will keep
> it as is; I also regard it as a good thing if the two
> programs keep a different approach to formula typesetting.

the latter is fine with me (although I don't think that geqn
is much more "automatic" than the original one). my point is
that  `eqn'   should  always  by  default  produce  visually
pleasing/acceptable output. the manual rather clearly states
that using additional explicit spacing means "tweaking". one
should not need to do this _always_.

so  my main point is: it seem's that the "ancient" kernighan
eqn manual shows that `eqn' produces sufficient  spacing  in
it's output without providing explicit "~" or "^" directives
and heqn does'nt do this. (at least not everywhere: e.g.  in
"f(y/2)"   in the above example heqn puts more space between
"f" and "(" than geqn.)

> 
> > and   unfortenuately   both   eqn   preprocessors   are  not
> > interchangable. another question would be: could the  output
> > be  made  compatible  (it  should  be, if `groff' did not do
> > groff-specific things in the troff commands emitted by  eqn,
> > right?)
> 
> It is generally no problem to use geqn with Heirloom troff;
> there is not even a need to turn groff compatibility mode on.
> The one thing which I know not to work is the placement of
> the parts of large brackets and parentheses. The reason for
> this is that Heirloom dpost (not my idea, but part of the
> original dpost design) tunes the glyph placement of the
> PostScript Symbol font to work with unmodified original eqn
> output. This gets in the way when geqn expects the glyphs
> to be positioned as with the standard Symbol font.

seem's  not  to be true if I don't do something silly wrong.
with the above example formula (say in file "tt") and

geqn tt | groff -ms > tt.ps
heqn tt | htroff -ms | dpost > tt2.ps
geqn tt | htroff -ms | dpost > tt3.ps

only  the  first  two work. the third produces an empty page
when viewed in `gv'.

joerg


PS: and if werner is reading this: geqn seems to ignore part
of explicit provided spaces "~" in  the  above  example  (it
seems  to  be  the default spacing anyway). is this intended
behaviour: "increase  spacing  only  by  the  difference  of
explicit provided space and default space"?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]