[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> That's not the fault of groff, but you are not willing to accept the
> standard.
There has never been any IETF RFP, nor ANSI/ISO/W3C committee work.
Thus, there is no de jure standard here, only a de facto one.
In any case, I already said I would be willing to implement these
extensions if my doing so actually solved the problem. But it
wouldn't, as Gunnar Ritter showed me and has since done a good job of
demonstrating to others.
> `groff' is the standard; it is available on all operating systems
> and it is free. So there should not be a problem to use it. If
> some programmers want to cook their own soups they are forced to
> take over the standard.
I'm not sure I understand your English, but noticing that these elaborate
extensions create more problems than they solve and deprecating them seems
like "taking over the standard" to me. So this discussion seems to
constitute doing exactly as you recommend.
> `grohtml' is able to transform all
> man pages indluding your enemies to a beautiful html output.
As at least two people other than me have explained at length, grohmtl
produces very thin and poor HTML. It's not "beautiful" because, among
other things, it doesn't meet the needs of people doing accessibility
work for the blind.
> How about integrating `doclifter' into `groff' as generater for `docbook'
> output? `groff -Tdocbook' would be very nice.
Can't be done -- and I really mean *can't* be, it's not merely a
difficult but possible thing like implementing the strange groff
extensions in your pages. The structural analysis in doclifter relies
on information that gets thrown away during macro evaluation.
> If you do not want to integrate the `groff' standard you have to rename
> your program to `classicaldoclifter'.
I have pointed out that there's no de jure standard, unless you know
of some standards document pertaining to troff that the rest of us are
all unaware of. If there is a man-page standard, it's a de-facto one,
what man-page authors actually use. Here are the statistics from my
latest test:
Total: 13117 man pages
Patched: 390 (2.97%) -- these are mostly for outright markup errors
With patches: 99.47% -- so doclifter fails to lift only 0.53% of pages
Without patches: 96.49%
And these figures are worse than normal because (a) I haven't reintegrated
the 349 fix-patched netpbm pages, and (b) at the moment I have a bug in
processing C function synopses that contain .PP tags, which I expect to
fix shortly. When I get these things done, my clean-conversion rate
will be somewhere around 99.51%, possibly higher.
Are you really prepared to argue that a program that converts 99.51% of
well-formed man pages and over 96% even when you include broken ones is
not meeting the de-facto standard? The way this discussion has been going,
if you do maintain that position you are likely to find yourself in a
minority of one.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
