Re: [Groff] nroff vs. troff conditional using escapes?

[Michael(tm) Smith]

Steve Izma <address@hidden>, 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