Re: [Groff] Mission statement, second draft

[Ingo Schwarze]

Hi Ted,

Ted Harding wrote on Wed, Mar 19, 2014 at 07:01:48PM -0000:

> A lot of this discussion (which I have tended to keep out of, because
> it is about issues that rarely concern me; and also has not always
> been clear) has been about creating a new, and structured, approach
> to the formatting of manpages, especially with reference to making
> them browsable. I can grant that there is a need for this.
> 
> QUESTION: It has not become clear to me, from this discussion,
> to what extent this might interfere with core groff.

I is not going to interfere with core groff at all (or the groff
backend, how Peter calls it in his draft).  The reason that it won't
interfere is that the structure is represented purely on the macro
level, so as soon as you run groff on it, the structure is gone,
anyway.  Designing macros such that they express structure does
neither require nor preclude new backend features.  It's orthogonal.

This is also true for mdoc(7), the semantic markup macro language
for manual pages designed 25 years ago.  Or do you remember that
it interfered with roff backend design or implementation, at any
point in time?  The same will no doubt hold for man(7), whatever
Eric might do with it.

> At times, Eric Raymond has written as though this would involve
> a complete re-make of groff, with the potential inplication that
> use of groff for other purposes, and especially documents with
> "printed-page" layout, would involve a complete revision of how
> one would work with groff (e.g. classical macro sets would
> themselves become obsolete);

I think you misunderstood what he said; i remember him saying
(1) that he does not intend to take anything away from classical
typesetting features and that (2) he considers high-quality printed
typesetting to be the niche where groff can excel and flourish
(rephrased from memory in my own words).

> and indeed has hinted that the printed page itself is
> becoming obsolete so that there will soon be no need for the
> traditional capabilities of {g|t}roff.

Well, hundred years ago, all publications involved printed pages,
and fifty years ago, everything except radio and television.
That's no longer true today, so in that sense, printed paper
has lost some ground.  But it's not quite gone yet, and even
if we would decide to extend groff into the direction of epubs
or whatever (which even Eric doesn't plan to do, as far as i
understand) it would be stupid to do that at the expense of
PostScript and PDF output, the current main strength of groff.

> SO: Supposing that this proposed enterprise goes ahead, WILL WE
> STILL BE ABLE TO USE GROFF AS WE ALWAYS HAVE DONE?

Definitely.

> I'm speaking here of non-manpage work. For myself (and other will
> certainly think differently), I'm quite happy to enter "man XXXX"
> in a terminal and scan through what comes up. If others prefer to
> access it differently, that's fine, so long as making it possible
> does not interfere with how I use groff!
> 
> If there is incompatibility between a new approach to manpages, and
> non-manpage traditional use of groff, then I would say: Let the
> manpage issue be made completely separate from traditional groff.
> A completely separate program "manroff" if necessary! From my point
> of view, manpages must not interfere with core groff.

That program already exists, as a complement, not a replacement for
groff, it is called mandoc(1):

  http://mdocml.bsd.lv/

For the terminal, it strives to produce byte-by-byte identical
output with groff.  So it is *not* incompatible with groff,
quite to the contrary.  The main motivations are that for mdoc(7),
it's typically four to five times faster than groff, for man(7)
about two times, that it can produce better [X]HTML output, that
it can do automatic mdoc(7) to man(7) conversion, and that it
provides semantic search capabilities.

Regarding PostScript and PDF, you need not take it quite seriously,
that's still groff's domain - nota bene, starting from exactly
the same source files, in exactly the same macro languages.

Yours,
  Ingo