[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] groff as a backend
From: |
M Bianchi |
Subject: |
Re: [Groff] groff as a backend |
Date: |
Thu, 16 Dec 2004 17:06:47 -0500 |
On Tue, Dec 14, 2004 at 11:06:58PM -0500, Larry Kollar wrote:
> Otavio Exel wrote:
> > groff sources are intimidating and I can easily understand if many
> > non-geeks decide to use MsWord instead.
> > but what I can not understand is why groff is not more widely used as a
> > backend for other document systems. the abscence of a groff backend in
> > Texinfo and Jade are particularly intriguing to me..
> >
> > is there a reason that I'm not aware of?
>
> There was a time where commercial troff was not easily available due
> to expense, and GNU troff was not yet extant. During that time, TeX was
> free and freely available, so that's where the community moved. Inertia
> has kept them there. But the Unix Text Processing book is now available
> online (see my .signature); there's no free equivalent for TeX, LaTeX,
> Texinfo, or DocBook that compares in quality or depth of information, so
> perhaps we'll start seeing more people adopting groff in the future.
I've been using troff since 1974, so I'll toss in my 2-cents ...
The idea of a backend engine for the computation of documents (as opposed to
the WhatYouSeeIsWhatYouGet or WYSIWYG construction of documents) is a good one,
and that is why I use groff/troff/nroff for mine.
But groff is very much an early generation, assembly language-like environment
for computing documents. To my mind it is not really a best-of-breed solution,
more of a the-best-we-have-right-now. (That is a sad statement, now that I
think about it.)
To be a best-of-breed, it would need to acquire the ability to both create very
pleasant type-setting of common sentences, paragraphs, sections, chapters, and
such (which the mm and ms macro packages do pretty well) AND be able to
_easily_ construct key-stroke graphics (and other very specific typographic
layouts) with utter accuracy and certainty. Even with simple tables, I always
have to go thorough repeated hack-and-view cycles to get a specific layout or
to avoid unfortunate placement. For instance, the management of typographic
widows and orphans should be completely automatic with easily tunable
parameters. I expect we each have a long list of "*roff annoyances".
So I think there is a lot of work needed to make a reasonable back-end for
typesetting that could be shared by many front-ends. Namely there needs to be
something like the "structured programming" and LALR parsing concepts that
brought engineering disciplines to programming languages. I think the *roffs
probably have the computational capabilities needed, but not an expressive
structure that would make the construction of various front-ends a pleasant
job.
Maybe, my next life, it would be fun to be part of a community tackling that
problem.
--
Mike Bianchi
Foveal Systems
973 822-2085 call to arrange Fax
address@hidden
http://www.AutoAuditorium.com
http://www.FovealMounts.com
- Re: [Groff] groff as a backend, (continued)
- Re: [Groff] groff as a backend, Werner LEMBERG, 2004/12/17
- 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, 2004/12/16
Re: [Groff] groff as a backend,
M Bianchi <=
Re: [Groff] groff as a backend, Bernd Warken, 2004/12/17