[Groff] Mission statement, second draft

[Peter Schaffter]

Here's the second draft of the mission statement, incorporating
suggestions from Ingo, Eric, Pierre-Jean, and others.  It's starting
to come into focus, although a third pass will probably be necessary
before we commit to it.

I've dropped all mention of the build system, which, as was pointed
out, is an administrative concern and doesn't belong in a mission
statement.

The section dealing with manpages had me hemming and hawing for
days.  The original wording wasn't vague; it stated the matter
clearly--the intention to improve the semantic usefulness of
manpage markup.  Details of strategy/implementation were omitted
because the issue is a minefield, and part of our mission will be
to navigate through it gracefully.  Whether, as Eric proposes, we
tinker with man(7) so it plays nice with DocLifter, or, as Ingo
proposes, we advocate a migration to mdoc, the goal remains the
same: semantically clearer manpage markup for easier conversion to
xml.  (Ingo spotted the reason for my general wording right off that
bat, as did a few others.)

Nevertheless, I've rewritten that section of the mission statement
outlining Eric's strategy for dealing with the manpage-markup=>xml
challenge.  I don't expect it to be final, but here are my reasons.
(I'm non-partisan, merely trying to clear things up for a mission
statement.)

1.  No matter how successfully mdoc/mandoc have replaced man/groff
    in BSDs, groff remains a GNU project.  Ingo's strategy comes
    awfully close to touching on GNU policy itself, which doesn't
    belong in a groff mission statement.

2.  Ingo's strategy entails social engineering ("...actively
    supporting the transition from man(7) to mdoc(7)").  So does
    Eric's, however Eric has already done a lot of work on that
    front with respect to man(7), getting package maintainers and
    developers to clean up their markup.

3.  Eric's strategy involves specific tasks that can be be shared
    amongst developers.  Witness the immediate response to his
    '.hygiene' proposal.  This very good for the health of groff,
    even if our primary focus is improving the backend.

4.  Eric's strategy does not preclude ongoing support of mdoc,
    which--who knows?--may become the future standard for manpage
    markup throughout the known GNUniverse.  On the other hand,
    Ingo's strategy proposes a radical shift that basically
    kills man(7).  I favour active development of both, letting
    evolutionary principles determine which is the more fit for an
    xml-based ecosystem.

On the subject of implementing Heirloom troff's paragraph-at-once
formatting and associated goodies, I wrote Gunnar about it.  Here's
what he had to say:

 "Sorry, but I haven't done anything related to those topics for
  several years.  I've never looked much into the groff code.  From
  what I remember, the fact that it was in C++ alone made it so
  different though that there were few if any similarities at a
  superficial glance.

  Implementing paragraph based line breaking took me several weeks
  back when I was intimately familiar with the surrounding code.
  The algorithm itself is complex and takes some time to understand.
  And then there is the task of rewriting large portions of an
  existing environment that assumes line based formatting."

Which is by way of saying it's going to be a big job, and we *must*,
as a group, figure out how to attract programmers interested in
tackling it.  Line-by-line formatting is, IMO, the single biggest
stumbling block to more widespread adoption of groff as a
typesetting system.

--------------------------------------------------------------------

GROFF MISSION STATEMENT, 2014, 2nd draft

As the most widely-deployed implementation of troff in use today,
GNU troff (groff) holds an important place in the Unix universe.
Along with TeX, it plays a leading role in the development of free
typesetting software for Unix systems.  While maintaining backward
compatibility, it continues to evolve as a sophisticated typesetting
system with the advantages of small size, portability, and speed.

Future groff development will focus on these areas:

- improvements to the backend
- active development of general-purpose frontends
- the man(7) macros

Backend

The biggest challenge facing groff is the implementation of
paragraph-at-once formatting based on the Knuth-Plass algorithm.
Already present in Heirloom troff, this is a high-priority next step
in groff's evolution, along with the addition of typesetting
features modelled after Heirloom troff.

The behaviour of some existing requests will also be reviewed, with
care taken to maintain backward compatibility if modifications are
deemed worthwhile.

Equally important for groff's future will be instituting native
support for TrueType, OpenType, and other non-Type1 (PostScript)
fonts, as well as improving Unicode support.

If possible, some historical encumbrances (read "annoyances")
will be removed, e.g. integer arithmetic and linear evaluation of
expressions at the request level.  Again, a watchful eye will be
kept on backward compatibility.

General-purpose frontends

The most active area of development in the past decade has been
directed toward typesetting frontends, with the mom macroset
alone adding over 13,000 lines of macro code to the project.
Well-designed, well-documented frontends are important because they
help make groff accessible to a larger number of users--new users in
particular.  Support for existing macrosets and the development of
new ones are key to groff's future.

The man(7) macros

The need for Unix manuals to render cleanly to multiple output media
favours the use of structural rather than presentational markup, but
the classical, widely-used man(7) macros are largely presentational.

Considerable work has already gone into man(7) => xml conversion
(DocLifter); there remains enhancing man(7) itself to assist with
the process.  The goal is to decouple the macros as much as possible
from low-level troff requests and semantically enrich the markup
*while preserving backward compatibility.*

In all areas of future development, backward compatibility will
remain a top priority, as will avoiding feature-bloat and increased
overheads.  Groff's viability and vitality rest as much on these as
on forward-looking development.

Finally, it is hoped that users of and contributors to groff will
promote its use, providing unobtrusive advocacy to encourage more
widespread adoption of the program, thereby increasing the pool of
potential contributors and developers.

--------------------------------------------------------------------

-- 
Peter Schaffter
http://www.schaffter.ca