Re: [Groff] groff as a backend

[Meg McRoberts]

I love what you say about your mind not being wired for GUIs,
Ted -- I feel the same way.  Alas, for people whose minds ARE
wired for GUIs, it seems that our beloved groff tools are
even harder to grasp.

So the question becomes whether it is possible to come up with
WYSYWYG tools that allow the GUI-type people to function yet
still allow people like us to use the raw tools.

I don't think I can recommend that a company that has a large
group of writers and will have regular attrition and rehiring
set up their doc set in the groff tools for this reason.  The
learning curve is just too steep and it seems that one really
needs to have a professional groff tools person on-board if one
needs to do a large set of documents.

If we had a WYSYWYG front-end that was as powerful as other WYSYWYG
editors, it would be different.  It doesn't need to be as powerful
as raw groff if one can still work in raw groff.

At my current job, I am writing highly-technical material in Word
of all things!  Bleach!  But we have support and sales people who
need to sometimes cut-and-paste the material and make minor edits.
But we can't do any sort of true source code control and Word
formatting is a nightmare, especially when one does cut-and-paste.
This is why I've been thinking about XML with XMetal or a similar
front-end (I think there are some decent ones out there that have
a free version for the masses and a professional version for the
writers).  But my heart is still with groff -- I would like nothing
better than to be able to use it for everything!  

meg

--- address@hidden wrote:

> 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 ------------------------------
> 
> 
> _______________________________________________
> Groff mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/groff
>