Re: [Groff] groff as a backend

[Ted Harding]

On 16-Dec-04 Larry McVoy wrote:
> [...]
> Side note: I'm about to bitch about the problems I see with roff.
> [...]
> I think one thing that is missing is a WYSIWIG system which spits
> out roff on the back end.

Bearing in mind what others have written in response, here are
some further comments.

As to a conventional "WYSIWYG" (i.e. the user edits in a graphics
screen where he has the impression of working on the formatted
output, à la Word), I'm inclined to think this is not well suited
for groff. I'm inclined from experience to think exactly the same
for TeX/LaTeX, with reference to LyX and Scientific Word. I had
hoped to improve my acquaintance with TeX/LaTeX by working with
LyX as a sort of initiation, but found LyX hard to use to get
desired effects, and actually found it was easier and more profitable
to work with a text editor on the source file. Later, trying
out Scientific Word, I found similar problems.

One reason for this is, undoubtedly, that my brain circuits are
not adapted to GUI. It's OK, I find, for single-action buttons
(e.g. clicking on "send" in an email MUA), but as soon as things
get more complicated than that, and especially when I want to
do something not quite standard, then the resources of the GUI
do not seem to be adapted to what I want and, even if they may
be adapted, the adaptation seems to be buried so deep in the
maze of the menu hierachy that I end up lost and wasting a lot
of time (and, if you're wondering just how a hierarchical
structure can map to a maze then let me assure you that, in my
brain circuits, that's exactly what happens with document-formatting
GUIs).

I think, though, that another reason is that the GUI can only
easily enable the user to achieve what has been built in to the
GUI. I'm sure that most if not all users of groff and TeX want
to be able to control their layout directly, by planting the
appropriate tags in the source file, and not be dependent on
what someone else has thought you may want.

On the other hand, it is fairly straightforward to achieve
what I call "delayed WYSIWYG" with groff (and I have seen it
achieved in TeX with what, if I recall correctly, is called
"ActiveTeX").

Essentially (and I have posted a Unix/Linux script for it
before), you use a script which

1. Creates initial groff source and PostScript output files
2. Opens 'gv' to display the PS file, 'gv' in "watch" mode
   (i.e. as soon as the PS file changes it re-reads it)
3. Watches the groff source file and, as soon as it changes,
   runs 'groff' on it, thereby chenging the PS file (see (2)).

Then the user types in groff source, using a favourite editor
(mine is 'vim'), every so often (when wanting to see the result)
saving the file (":w" in vim). Within a second or two of
saving, the 'gv' window displays the new formatted output.
I find this combines the best of both worlds: Almost immediate
visual feedback of the formatted result; the benefits of directly
entering the groff text.

> Another problem is that the design of the roff suite of tools
> is a series of filters.  I.e., pic | eqn | tbl | groff.
> The problem with that is that the earlier stages of the pipeline
> don't have enough knowledge of the state of the doc when they
> are called.  It made sense in the old days when CPU was expensive
> but it makes *no* sense today.  It would be much better if
> groff invoked a new pic or eqn or whatever process as groff hit
> the  .PS/.PE markers.  That way the pic subsystem can know all
> about the current font sizes, for example, and you could have
> things like 
> 
>      box fit "foo bar"
> 
> work, where work means "make the box fit around the text".

I've often worked round this one too. The trick is to write
out commands for 'pic', 'eqn' or 'tbl' to a temporary file,
when you know what you want to write out. This file will
contain 'pic', 'eqn' or 'tbl' commands based on information
available to groff at the time they were written out.
Then using ".sy', you run 'pic', 'eqn' or 'tbl' on it and save
the output to a new file which you then read in when wanted
using "'so". Simple example:

.ds btxt This is very very very very long text
.nr bw \w'  \*[btxt]  '
.nr bh 2m
.de tmp1
box wid \n[bw]/72000 at (1,1) ht \n[bh]/72000 "\*[btxt]"
..
.opena stream1 strfile.pic
.write stream1 .PS
.writem stream1 tmp1
.write stream1 .PE
.close stream1
.sy pic -Tps strfile.pic > strfile.tr
.so strfile.tr

Of course this is a bit tedious, and is would be useful to
automate it somewhat. It should be doable with suitable macros,
but I confess I have never taken the trouble to write them.

You can also use this approach to exploit the capability of
'pic' as a numerical calculation engine. For this purpose I
redefine .PS and .PE so that when given the argument "T" (for
"tacit") there is no visible effect in the output. Then .PS
and .PE serve only as signals to 'pic' that what comes in
between is material for 'pic' to process. 'Pic' can then be
used simply for calculation, and since you can send commands
to groff within pic using the gpic extension "command" you can
make tghe results available to groff (e.g. as string registers).
So, for instance,

.ds rawprice 22.50
.ds vat 1.175
.de tmp2
>>> and write out the following to an external file for 'pic'
.PS T
command .ds[price] sprintf("%.2f",\*[rawprice]*\*[vat])
.PE
<<<
whereupon when groff ".so"s the file after 'pic' has been run
on it as above, you have the string register \*[price] with
the value "26.44".

All this sort of thing allows you, for instance, to read in
data files in the course of processing groff source, and have
the results of calculations on the data inserted in the
appropriate place.

> Another problem is that roff is single pass. This makes widow
> and orphan processing pretty much impossible.

I'm inclined to agree with this, though not sure that the true
source of the problem is "single pass". I think it rests more
on the fact that groff deals woth output formatting output-line
by output-line, and once a line has been output you can't pull
it back. TeX has an algorithm for formatting a whole page as
a unit, allowing the whole page to be tweaked before being
output. In groff, it might be possible to set up a "page"
diversion, where it would then be possible to decide whether
or not to add a line to the page depending on the formatted
height of the contents of the diversion at that [oint.

> It also makes things like table of contents be something you
> have to do outside the system.

Others have commented on this. I don't really see this as
a problem, and indeed welcome the opportunity it gives to
create TOC, indexes, etc. using external software which may
not be part of groff.

> Finally, there is the whole problem of "glitzy". We need good
> image and color support.  Lots of docs want this.

For printing, and for display in PostScript or PDF, I've never
found groff wanting when it comes to "glitz"!

> All that said, roff is still my system of choice.

Hear, hear!

Best wishes to all,
Ted.


--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861  [NB: New number!]
Date: 16-Dec-04                                       Time: 21:07:05
------------------------------ XFMail ------------------------------