Hi Peter,
Peter Schaffter wrote on Mon, Feb 24, 2014 at 09:59:43PM -0500:
[... snipped many interesting thoughts, in particular regarding
the question where the problems do *not* lie ...]
> As for xml output, I'm convinced that's a source file, macro level
> issue. The mom macros point the way for xml-friendly structuring of
> source files; who knows what a joint-development effort in a similar
> vein could accomplish?
Actually, there already is an example out there of what it can
accomplish, even though that example has much room for improvement
still; even though its HTML output looks nice in a browser, the
code quality of the HTML code generated is still mediocre, but that
is easy to improve. I just wasn't that interested in -T[x]html so
far and barely kept it alive, not doing any work there unless it
was absolutely required.
You see, mom(7) is not the only example of a roff macro set supporting
the transformation you describe. There is also mdoc(7). The
metadata part is short (just Dd Dt Os Sh NAME Nm Nd), stylesheet
information is not usually included but kept in a separate file
because you usually want to apply style to more than one document
at a time, but what matters is that, in a well-written manual, the
main part that follows Sh DESCRIPTION contains almost no
presentation-level markup, just as you described. Of course that's
much easier than in the mom(7) case because the presentational needs
of a manual are much more modest than those of a general-purpose
mom(7) document.
When Kristaps started out with mandoc(1), he advertised it as a
way "to deprecate groff for manual display",
http://2009.asiabsdcon.org/live/abc2009-P6B.html
which was occasionally misread as "to deprecate groff".
Right now, i regard mandoc(1) as a groff companion tool rather than
a replacement for groff, even with respect to manuals. While there
is nothing wrong with mandoc(1) implementing simplistic -Tps and
-Tpdf output modes for people who are in a hurry and have modest
needs, groff is really the tool for producing quality typeset output
even of manuals.
In the framework you propose, mandoc(1) is just one of the "source
file, macro level" tools to convert semantic roff-macro input into
something that supports stylesheets, i.e. one of the smaller tools
that support groff. Interestingly, that is actually close to
Kristaps original idea, and that's where the old name "mdocml",
"mdoc to markup language", comes from. So Kristaps had the task
you describe in mind before he ever started thinking about terminal
output - where it doesn't really matter that much whether you use
mandoc or groff, except for speed, code size, code simplicity
and maintainability, and restrictive licensing.
We did not notice until now that this is, as you just described, a
general task, extending much beyond manuals, applying to all macro
sets and to the choice of good macro sets in particular. But your
reasoning now makes a lot of sense to me.
What is a bit surprising at first is that such supporting tools,
converting semantic-macro input to something linking to stylesheets,
are not likely to have any opportunity for sharing any source code
with the main groff/troff codebase. But they are still groff tools,
in the sense of making the roff and roff-macro languages more useful
for new-fangled virtual typesetting needs, and thus supporting the
use of groff for the real, hard, classical typesetting part.
> Again, sorry for the long post.
Rather, thank you for sharing these thoughts.
Yours,
Ingo
