[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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]