[Groff] A progress report

[Eric S. Raymond]

This is for Ted Harding and others who have felt they weren't being 
sufficiently informed about the changes I've been making.  Comments
and suggestions welcomed.

1. EQN

The new MathML back end to eqn continues to just work.  

I thought I had come up with a way to implement mark/lineup, but there
turns out to be a fundamental problem.  The way the troff back end 
does it relies on treating multiple adjacent .EQ/.EN spans as a single
display -- as in this classic example from the original eqn guide:

.EQ I
G(z)~mark =~ e sup { ln ~ G(z) }
~=~ exp left ( 
sum from k>=1 {S sub k z sup k} over k right )
~=~  prod from k>=1 e sup {S sub k z sup k /k}
.EN
.EQ I
lineup = left ( 1 + S sub 1 z + 
{ S sub 1 sup 2 z sup 2 } over 2! + ... right )
left ( 1+ { S sub 2 z sup 2 } over 2
+ { S sub 2 sup 2 z sup 4 } over { 2 sup 2 cdot 2! }
+ ... right ) ...
.EN
.EQ I
lineup =  sum from m>=0 left (
sum from
pile { k sub 1 ,k sub 2 ,..., k sub m  >=0
above
k sub 1 +2k sub 2 + ... +mk sub m =m}
{ S sub 1 sup {k sub 1} } over {1 sup k sub 1 k sub 1 ! } ~
{ S sub 2 sup {k sub 2} } over {2 sup k sub 2 k sub 2 ! } ~
...
{ S sub m sup {k sub m} } over {m sup k sub m k sub m ! } 
right ) z sup m
.EN

Notice that there's a mark in the first span and lineups in
the second and third.  

The only way this can be emulated in MathML is by merging these
spans and emitting a single big hunk of MathML consisting of
a one-column, three-cell table with <malignmark> elements
constraining the layout.

Generating the <malignmark> tags at the right place is trivial (I've
already done it in an experimental version) but changing the MathML
back end so that it will be able to wrap table markup around adjacent
spans would be hard.

It could be done. The back end would have to be modified to emit 
the output from each span into separate buffers, with a 
postprocessing stage to look for mark/lineup and decide when
span groups need to be wrapped.  

But this implementation would be, unlike the present code, messy and
complicated and bug-prone.  It's exactly the sort of thing a prudent
hacker avoids writing in C.

2. EXTENSION MACROS

These also continue to just work.  I have added documentation for them.

There's an open issue about whether an ellipsis definition should be
added to the extensions.

3. VIEWER-PORTABILITY AUDIT

All the easy manual pages are done.  I've just finished the first 
really difficult one, man/groff_out.man.

Which prompts a style observation.  If you're writing a page with 
subscripts but no other math markup on it, it's best to use troff
micromotions (\u and \d) rather than eqn.  The visual effect
is indistinguishable, and (unlike the eqn) the \d and \u pairs
can be lifted to DocBook subscript tags.

The remaining hard cases are groffer.man, groff_char.man, 
groff_hdtbl.man, groff_mdoc.man, groff_mmse.man.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>