OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook-apps] manpage/docbook.xsl generated code broken for nroff


Hi,

Am 08.02.2009 um 09:27 schrieb Michael(tm) Smith:

> Ralph Bö嚠me <ralph@rsrc.de>, 2009-02-03 22:34 +0100:
>
>> Am 03.02.2009 um 22:16 schrieb Bob Stayton:
>>> I don't have a system with plain nroff to test this on, so I'm not  
>>> clear on
>>> what exactly the problem is or how to fix it.
>>
>> If you like I could provide you shell access to a Opensolaris 11/08  
>> machine.
>
> That would help me. We have open bugs on this that are assigned to
> me, and I am hoping to get some fixes made and checked in
> relatively soon, and then do a 1.75.0 release after that.

OK. Please send me your ssh pubkey. Login will be then:
`ssh -p 20024 msmith@85.183.11.35`

That host is generally not up 24x7 so if you can please tell me at  
what times you're
gonna be working on this and your TZ.


>>> Do you know if the issue is the use of macro
>>> names longer than two characters, or the use of built-in groff  
>>> instructions
>>> that don't work with plain nroff?
>>
>> The latter. Running `checknr` (a nroff syntax checker) bails out  
>> numerous
>> times.
>
> I hadn't know about that tool.

Well, I'm not sure if it will be useful in the end: it bails out on  
`checknr /usr/share/man/man1/ls.1`
too. ;o) And it doesn't know the man macros.

>>> If it is the former, then it could be
>>> easily fixed by renaming defined macros, but if it is the latter,
>>> then it will be harder.
>>>
>>> If you manage to get a new 'define.macros' working, you could  
>>> submit it for
>>> inclusion and we could add it to the stylesheet with an option  
>>> parameter to
>>> turn it on.
>>
>> I got one working by completly removing the 4 mentioned macros:  
>> toupper,
>> SH-xref, SH, SS. See:
>>
>> <http://netatalk.cvs.sourceforge.net/viewvc/netatalk/netatalk-docs/manual/man.xsl?revision=1.3&view=markup 
>> >
>
> So, what I'll probably end up doing is to create a new parameter
> named "man.custom.macros.enabled" (or something) and have it set
> to on by default. Setting it to off will cause the custom macros
> to not be used.

What was worrying me is if the generated *roff code relies on and uses  
these macros ? I.e. if I just remove them via a custom XSLT stylesheet  
or if you provide a parameter to turn it off, will the the generated  
*roff code use this macros defitions for its output ? Or are these  
just re-definitions ?

Regards
-Ralph


smime.p7s



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]