[pdftex] PassiveTeX

[Rolf Dieterich]

> > because there are still substitutions which have to be done during
> runtime.
> > So do all my xsl-statements in the .fo file have to be escaped in some
> way or
> > is it possible that the FO processor doesn't touch the xsl namespace at
> all?
> 
> I am not sure what you are getting at here

When I've been speaking of "fo processor" I meant the part of PassiveTeX
which generates the tex code. So I probably should be more precisely. Let's use
these terms:
PassiveTeX FO processor = PT code generator + PT renderer (which is pdfTeX)

At the moment I have this solution:
1. .src + .xml --> .tex at runtime with MSXML
   .src containing a mixture of XSL and TeX code
   the XSL transformation used for templating
     (incorporating the user data from the XML file)
2. .tex --> .pdf with pdfTeX

My first approach with PassiveTeX:
1. .src --> .xsl with the PT code generator
   .src containing XSL-FO but also XSL statements to be preserved for step 2
2. .xsl + .xml --> .tex with MSXML at runtime
3. .tex --> .pdf with pdfTeX

Giuseppe suggested this production chain, all done at runtime:
1. .src + .xml --> .fo (with the XSL processor)
2. .fo ---> .pdf with PassiveTeX

Some consequences of my approach would have to be:

1. the PT code generator would have to generate something like

  \begin{table}
    ...
    &
    ...
  \end{table}

It would have to output the XML entity &, not the character & because
between the tex code generation and the text setting with pdfTeX, I want to
start another XSL transformation.

I guess it's impossible to urge the PT code generator to do that. Some
search/replace on my side would definitely stille be necessary between step 1 and
2.

2. Also, the tex code generator should preserve certain XSL statements like
<xsl:for-each select=...> which I need in my following step 2.
How would I have to formulate this in the input file for the PT code
generator in order to obtain the right output from it?

Would it be
  <xsl:for-each select=...>
which would be fine, or is it
  &lt;xsl:for-each select=...&gt;
which is uglier, or
  <xsl:text disable-output-escaping="yes">
    &lt;xsl:for-each select=...&gt;
  </xsl:text>
?


By the way, the text nodes in the XML file which is produced by my
application at runtime also needs escaping. Twice, regarding XML as well as TeX.
For example, if the end-user types "J.R. Ewing GmbH & Co. KG" the ampersand
has to be translated into \&amp; in order to obtain & as a printing character
at the end of my building chain.

If my building chain is different (steps in different order, another
templating mechanism, another typesetting system) the token translator would have to
be changed. So you better use some kind of design pattern in your
application to be flexible for the future.

I found escaping the TeX commands when producing the XML file much easier
than to make extensive use of verbose-environments/commands in the TeX file.


> > I have no idea, it's all still brainstorming, but I wonder if it
> wouldn't be
> > possible to implement the FO processing as a pure XSL transformation
> (with
> > an XSL stylesheet
> 
> transform to PDF? conceivable, just, but very very hard

No, I only meant generating TeX code.
For example, XML --> XHTML is done via an XSL transformation (XSL
stylesheet). Now XHTML is an XML dialect, like MathML, WML and so on. I wonder if it
would be also possible to produce TeX (which is _not_ an XML dialect) purely
with means of an XSL processor by applying some XSL stylesheet.


> my recommendation - look at ConTeXt. it has the most reliable and
> advanced macro programming for processing XML


I definitely should. As Thomas Merz wrote in the German PostScript & PDF
bible on p. 368:
"Obwohl ich es noch nicht aus eigener Anschauung kenne, möchte ich noch das
ConTeXt-Makropaket erwähnen, da es von vielen als die fortschrittlichste Art
angesehen wird, aus TeX-Quellen PDF zu erzeugen. Der ausgebuffte TeX-Experte
Sebastian Rahtz meint dazu: 'Bei ConTeXt-PDF-Dokumenten bleibt einem die
Spucke weg.'"

With best regards and probably without Spucke in the near future,

Rolf

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!