Steve Izma <[EMAIL PROTECTED]>, 2008-02-26 11:14 -0500: > On Tue, Feb 26, 2008 at 02:01:57PM +0900, Michael(tm) Smith wrote: > > Subject: Re: [Groff] nroff vs. troff conditional using escapes? > > > > So I think what would actually best for me to try to do is have > > my app always generated the \c before and after the string, and to > > preserve any whitespace that follows the string... > > I convert a lot of xml to groff using python with various parsers > (sometimes built-in python parsers, sometimes external like > nsgmls, which is extremely fast). I find that I can solve most > inline spacing problems with the solutions you and Clarke have > discussed, i.e., any time the parser outputs a text line my > script prepends \& and appends \c. Also, it seems to me that if a \c > starts a line, it gives the same effect as being appended to the > previous text line, but I rarely need to deal with this. > > Using such a python script as a preprocessor for groff is very > fast and allows you to do various kinds of string manipulations > at very little speed cost. For that reason, I've never bothered > to go the XSLT route.
I like Python quite a lot (though my Python chops are weak), but for this case, using Python or anything other than XSLT isn't really an option. The reason is that one of the core design requirements of the DocBook XSLT stylesheets and toolchain has been to try make it possible for users to take transform their DocBook source to various output formats with the smallest number of software dependencies possible -- so ideally, just with an XSLT engine (xsltproc, Saxon, Xalan). So the toolchain for generating both HTML output and manpages output requires only that (though the toolchains for generating PDF output also require an XSL-FO engine or dblatex, which uses a TeX backend). The HTML stylesheets have some optional features that require XSLT extensions (which are currently only available as Java and so require use of a Java-based XSLT engine). But even those don't require the user do to any additional post-processing (the stylesheets call the extension code directly). Anyway, for the case of trying to use XSLT to generate groff, the many and severe limitations in XSLT 1.0 have made it an interesting exercise at times. XSLT really makes you jump through a lot of hoops to correctly generate text output (as opposed to XML/HTML output). But at this point I do have it working fairly well, and supporting a good number of features (e.g., conversion of DocBook/HTML tables to tbl(1) markup, dealing with footnote and hyperlink handling even in TTY output, other stuff. Which is not to say it might not have been better to just not use XSLT at all from the beginning and go with Python or something instead. But I guess it's one of those roads that once you've started down, you sort of feel compelled to keep walking and hope it ends up leading somewhere interesting and/or useful... --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/
smime.p7s
Description: S/MIME cryptographic signature
