[Top][All Lists]
[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/
- Re: [Groff] groff as a backend, (continued)
- Re: [Groff] groff as a backend, Larry McVoy, 2004/12/16
- Re: [Groff] groff as a backend, Ted Harding, 2004/12/17
- Re: [Groff] groff as a backend, Larry McVoy, 2004/12/17
- Re: [Groff] groff as a backend, Ted Harding, 2004/12/17
- Re: [Groff] groff as a backend, Pete Phillips, 2004/12/17
- Re: [Groff] groff as a backend, Lars Segerlund, 2004/12/17
- Re: [Groff] groff as a backend, Gaius Mulley, 2004/12/20
Re: [Groff] groff as a backend, Larry Kollar, 2004/12/16
Re: [Groff] groff as a backend,
Larry Kollar <=
Re: [Groff] groff as a backend, M Bianchi, 2004/12/16
Re: [Groff] groff as a backend, Bernd Warken, 2004/12/17