groff
[Top][All Lists]
Advanced

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

Re: [Groff] groff as a backend


From: Larry Kollar
Subject: Re: [Groff] groff as a backend
Date: Thu, 16 Dec 2004 16:09:06 -0500

Larry McVoy wrote:

> I think one thing that is missing is a WYSIWIG system
> which spits out roff on the back end.

LyX could be made to do this by writing an export plugin
(essentially a script that converts LyX's internal document
format to something else). It might require a code tweak
to make groff conversion the default, but I believe that
could be done as well.


> ... 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 ...

That *would* be nice. The grog utility can already figure
out command lines based on the file given to it, so the
easy part's done already. :-) The "interesting" part
would be modifying groff to pass environmental settings
to the subsystem.


> Another problem is that roff is single pass. This makes
> widow and orphan processing pretty much impossible. It
> also makes things like table of contents be something
> you have to do outside the system.

Widow/orphan processing actually works if you turn it on
at compile time. I posted about it some time back...
http://lists.gnu.org/archive/html/groff/2004-03/msg00124.html

I don't think doing outside processing of ToC and Index
is all that bad. If you use -mm, there's a script called
"mmroff" that handles all that (plus cross-references).
It generates auxiliary files, but so does TeX (which is
multi-pass only because it automatically makes that second
pass for you).

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

That has improved; but I agree, it could be better. I'd
like to see groff/grops do the right thing with PNG images
without any help, for example. My work requires a mixture
of photos (usually PNG, a few JPEG) and line drawings
(EPS). I can drive conversions with make, but shouldn't
have to.

Having used legacy *roff 20 years ago, I can say that
groff is a vast improvement, and the old AT&T software
could easily do things that even high-end WYSIWYG tools
like FrameMaker have problems with. But are we ever
satisfied? ;-)

--
Larry Kollar     k  o  l  l  a  r  @  a  l  l  t  e  l  .  n  e  t
Unix Text Processing: "UTP Revival"
http://home.alltel.net/kollar/utp/








reply via email to

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