[EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> You have to solve your own problems instead of killing other good projects.
Right, which is why the groff pages need to be fixed so as not to kill
XMan, TkMan, Rosetta, and all other third-party viewers. My doclifter
is not even really the issue here, it's only the reason the issue has
surfaced.
> The stuff for blind people can be done within HTML. So `grohtml' can be
> fixed in order to do this.
There is a listmember who works with Braille-transcription software; I
suspect will shortly explain to you why this isn't so.
> But the output produced by `doclifter' is quite ugly in `openoffice'.
OK, what's 'ugly' about it? If it's just the XML layout, the right
fix is to run it through tidy(1). I left that capability out of doclifter
on the do-just-one-thing-well principle.
> And strange
> error messages are produced. For example, `doclifter' on `bash.1'
> produces the warning `warning: RS/RE seen.'. The `.RS/.RE' requests
> are absolutely normal `man' stuff, a warning is trash.
That's fixed in the 2.3 version -- no such warning is emitted any more,
and all .RS/.RE markup is turned into structure.
> A lot of things have to be done with `doclifter',
> so you could also do your `groff' problems.
I'm working now on doing better recognition of structural
patterns involving .br, .in, and .ti. But this is going to produce only
very marginal improvements, as the information needed to do really good
structural analysis simply does not exist at raw troff level.
Since the error rate got below 1%, I think it has been more efficient
to push patches upstream to fix broken things. Most man-page maintainers
seem to agree; I've had 203 patches accepted, and expect to see another
50 or more folded in during the next round.
Functionally I know of little else left to be done. Making
mandoc .Xo/.Xc work better is probably top of list, but even that would
rescue only a maximum of 14 manual pages out of 13,466 (some may already
format correctly, I need to recheck this).
Unfortunately for your case, .Xo/.Xc has a better claim on my time
than the odd groff extensions you rely on do. .Xo/.Xc is genuinely
necessary for those 14 pages; on the other hand, the macros extensions
that groffer.1 and the other groff pages at issue use could be
replaced with no loss in output quality by the .OP and .SY macros
Werner and I have been discussing.
> When the slime is replaced back to reason more will come.
Interesting sentiment. Very German. I doubt it will be widely persuasive
in any technical argument.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Groff mailing list
Groff@gnu.org
http://lists.gnu.org/mailman/listinfo/groff
