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