[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cannot typeset tmac/groff_mdoc.n
From: |
Krzysztof Żelechowski |
Subject: |
Re: Cannot typeset tmac/groff_mdoc.n |
Date: |
Wed, 26 May 2010 11:46:50 +0200 |
User-agent: |
KMail/1.12.4 (Linux/2.6.31.12-0.2-desktop; KDE/4.3.5; x86_64; ; ) |
Dnia wtorek, 25 maja 2010 o 17:37:27 Werner LEMBERG napisał(a):
> > Now to the output of -Thtml: [...]
>
> You've hit one of the weakest points of groff...
It is also (potentially) the most used point nowadays, as GUI systems prefer
to display manual pages in HTML: PostScript is too heavy and the X display,
while most accurate, does not allow to search or copy text. This is not a
problem for small pages; however, for pages like groff_mdoc.n it is
overwhelming (no page references in ToC, no concept index, no keyword index).
>
> Unfortunately, the author of grohtml no longer takes care of his
> `baby', and I don't have time either to work on it. For this reason
> grohtml is still tagged as `beta code'.
After giving this problem a second thought, I think grohtml is a
misconception. It is an attempt to reconstruct a high-level semantic
description (HTML) from a low-level graphic description (groff output). This
plan is bound to fail.
OTOH, I think it would be possible to modify existing mdoc sources to produce
semantic HTML directly via write or preferably via device-specific output
instructions; however, I am not familiar with groff output format so I cannot
tell whether that would be fully possible, but I know one thing for sure:
groff has no way to predict the font metrics in the browser that displays the
result so the output must be high-level to be predictable. And I envision a
construct-by-construct transformation to XML as a valuable intermediate step:
construct-by-construct is easy and XML-to-HTML is easy.
Please forgive me if these ramblings show only my complete lack of
understanding of the internal mechanisms of groff; it is a large and
complicated engine and I would obviously need a couple of weeks to understand
how it works.
>
> Additionally, the mdoc package has, contrary to ms or man, not been
> prepared for proper grohtml support yet. On the other hand, there are
> still some bugs directly in grohtml.
>
> In case you are interested in the latter, it would be of great help if
> you can construct minimal documents which exhibit erroneous behaviour,
> and submit them as individual bug reports to Savannah so that at least
> the problems get collected at a central place. Submitting patches of
> course is highly welcomed too (for example, to check the HTML stuff in
> `s.tmac' or `an-old.tmac' and do something similar in `doc.tmac' and
> its related files).
I think the bundled BUGS document should mention the Savannah URL.
Cheers,
Chris