Sat 29 Jan 2011 12:52:52 PM UTC, comment #3:
[This is from Christopher]
> Sorry for answering that late; this bug report has been completely
> below my
> radar.
>
> mdoc has been specifically constructed to be easily parseable by other
> programs also (especially having HTML in mind, I think), thus a
> solution like
> yours is a natural extension.
I did not try to parse mandoc on my own; I use the groff engine to do
it. The alternative approach you recommend, called man2html, is a
miserable failure and not worth maintaining IMHO.
>
> My knowledge of XML is very limited – is there any disadvantage to
> target
> HTML output directly? Why the XML intermediate step?
I wanted to change mandoc as little as possible without rewriting any
non-extension code and without adding any logic of my own. Therefore
I get, for example:
<li >a <li >b <li >c <li >d </li ></li ></li ></li >
from mandoc, to be pulled up to
<li >a </li ><li >b </li ><li >c </li ><li >d </li >
by the post-processor. This transformation is rather unnatural for
XSLT and XSLT was not optimised for it, so there is room to improve by
using another transformation engine; I picked this one because I tend
to be familiar with it :-) What is important is the idea of embedding
device-independent structural information in ditroff output.
>
> On the other hand: Why not improving grohtml to make it output better
> HTML?
> It should be straightforward to add more grohtml tags to the mdoc
> sources if
> necessary. The `more readable HTML' argument is of no importance
> IMHO.
>
If you read the principles of grohtml, you will learn that it is an
archaeologist trying to put broken pieces of pottery together. It may
sometimes work, and there is nothing better to do against an unknown
and unsupported macro package, but a slight modification of the macro
package can make the whole process much more robust by including the
metainformation as directives. (Grohtml does it in a limited way but
it is guesswork based on screen scraping; the only way to a
predictable result is to reproduce the semantic information conveyed
by document structure macros in XML directives.)
The 'more readable HTML' means also that it is more readable to
machines; it can be correctly indexed by crawlers styled to one’s wish
without modifying the code and read aloud to blind people according to
the authors’ intention.
Add to this the potential advantage of producing equations in proper
HTML or MathML.
> IMHO, working on grohtml is the better approach (at least from my
> point of
> view as the groff maintainer). What you have created would be a good
> template
> and guidance how grohtml output should (or could) look like.
It would be awesome if the maintainer of grohtml could offer a
comment. IMHO, the grohtml way cannot be significantly improved.
I have taken the liberty to summarise the present support for legacy
manual pages on X11 displays [2]. The picture is very disappointing
and I can see no way I could advise a non-technical person who is not
fluent in English to install and use free software under these
circumstances.
Thank you for your consideration,
Chris
|