> Seriously though - I have put an enormous
> amount of work into this project as have other developers, and we don't
> get much back from it...
Matt, I can feel your pain :-) Now is as good a time as any to steal
some worktime from my real job and go ahead to release
IDX-DocBook2LaTeX
Homepage is http://www.idealx.org/DocBkXML2LaTeX/
>From the freshmeat announcement (pending, #34715):
IDX-DocBook2LaTeX is a stylesheet which translates DocBook
documents (http://www.docbook.org/) into LaTeX. It is written in
Perl, using the XML::XPathScript package from AxKit
(http://www.axkit.org - also on CPAN). It is powerful (handles
tables, indices, figures, footnotes and more), and easy to extend
(thanks to the XSLT-like templating philosophy built in
XPathScript).
I gather the list is having endless problems rendering DocBook to PDF
inside AxKit - well, this software of mine may be of interest to you
then, and you may get results that look better than the nroff solution
:-)
> For a start, let me say emphatically that XPathScript isn't going away
> - for anyone using it right now it will still be there in AxKit in the
> future.
Thanks a lot Matt for this wonderful piece of software. To me,
XPathScript is the best of both worlds for XML and Perl. Taking
advantage of the design patterns in XSLT (templates/apply_templates,
cascading stylesheets, idea of not using any global variables and use
only XPath to reach a typesetting decision for each node), I was able
to tackle the daunting task of rendering DocBook (400+ tags) and still
produce maintainable code. More truly: my stylesheet is a *pleasure*
to maintain.
Using Perl, I was able to do output to LaTeX without (major - see
below) escaping headaches, and perform some really gory tricks when
needed: for example, I render <xref linkend="chapterfour"/> as either
``Chapter 4 (page 35)'', ``Chapter 4, page 35'' or just ``4, page 35''
depending on the text context (respectively: free context, inside
parentheses, and after the word "Chapter" if user said ``See also
chapter <xref linkend="chapterfour"/>''). Using REs and comfortable
flow control (``eat() until satiated();'') is a real plus there.
I do not fully understand the disparaging messages sent this week-end
against XPathScript, mainly because I do not use it in the AxKit
environment and therefore the underlying philosophy is a bit beyond me
- maybe this is because I am using XPathScript as the last XML
transform of my chain (And as regards content/presentation separation,
TIMTOWTDI, and not all of them pass through XML:-). For my problem,
anyway, the XPathScript programming model is a perfect fit.
> As far as downplaying XPathScript, well if that's how the community
> wants to play things then we can follow that notion.
Maybe we need a separate XPathScript mailing list then :-) It is true
that XPathScript could use some functional improvements:
* handle the Perl-UTF-8 issue more cleanly (Perl strings carry an
internal ``UTF8-tainted'' flag that causes untranslated UTF-8
strings in the output to contaminate the whole document);
* propose the C implementations of the XML parser and XPath engine
(e.g. XML::libXML) for speed, as pluggable alternatives to the
pure-Perl versions;
* a few API enhancements: disable the apply_templates() sloppy
behaviour w.r.t. parameter checking (I'd like to do
``apply_templates(@nodelist)'' even if @nodelist is empty, and the
old behaviour can be had simply with ``apply_templates("/")'');
add a template for ``text()'' (vital to remove all the ugly
Perl-hack stuff in my own code for XML->LaTeX text translation);
add a call_template() equivalent; add a way to determine whether
we are in the bottommost stylesheet in the cascade (so that one
can refrain from doing any output if not); etc.
* allow inline Perl/XPathScript code in XML documents through processing
instructions:
<?xml version='1.0' encoding="iso-8859-1"?>
<?perl
$randomStylesheetVariable=42;
?>
* rework the /usr/bin/xpathscript program: allow stylesheets to
reside in another directory, add a ``-e'' option to evaluate
arbitrary Perl code from inside the stylesheet package (would
replace XSLT stylesheet variables);
* a framework to painlessy share code between the standalone
XML::XPathScript Perl module and the in-Axkit module
Apache::AxKit::Language::XPathScript (I cannot do this by myself
though);
* a better documentation that points out the advantages of
XPathScript :-)
--
Dominique QUATRAVAUX Open-source software engineer
IDEALX
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
