groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: <OK> Re: [Groff] Re: Simplifying groff documentation


From: M Bianchi
Subject: Re: <OK> Re: [Groff] Re: Simplifying groff documentation
Date: Sun, 24 Dec 2006 11:45:23 -0500

On Sun, Dec 24, 2006 at 01:35:09AM -0500, Eric S. Raymond wrote:
>       :
> This is a much richer ontology than HTML, so man -> DocBook -> HTML
> produces best possible HTML.  man -> HTML, on the other hand, ends up
> translating man pages into a sort of least-common-denominator ontology
> between man and HTML.  You end up with really stupid, thin
> translations that throw away a lot of even the modest semantic
> information that man-page markup carries.

Since DocBook deduces _meaning_ from the presentation markup then I will claim
that the correct path needs to be something like ...
        groff -man  ->  DocBook  +->  HTML
                                 |
                                 +->  groff -man_extended

where new meaning markup is inserted back into the source document form
(assuming that  foo.man_extended  becomes the prefered edited file).

Using ESR's example, the original  foo.man  fragment ...
        .nf
        main( int argc, char *argv[] )
        {
                // more C code
        }
        .fi

would become the new  foo.man_extended  fragment ...
        .SourceCode_Start
        main( int argc, char *argv[] )
        {
                // more C code
        }
        .SourceCode_End

I see the goal as making the edited source document file more easily editable
by including more meaning markup.  (I now see that this was also the goal of my
suggestion of using a wiki interface.)

-- 
 Mike Bianchi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]