> -----Original Message----- > From: Stepan RYBAR [mailto:[email protected]]
Hi Stepan, > is it possible to perform XSL-T (2.0) transformation within FOP (1.0), > *where input file is in IntermediateFormat*? > I tried it, but without success (something like unable to mix input mode). AFAIK, this case is not yet accommodated in FOP 1.0. At least, not from the command-line. I guess the rationale behind this is that people who use the IF are considered 'power users', and thus they should have no problem implementing my below suggestion. If you are slightly versed in Java and would use FOP embedded, this should almost turn out to be the proverbial piece of cake. I would suggest to look closely at a few of the examples that are distributed with FOP. See if you can write a small Java wrapper that renders your 'in.xml' to the IF, uses that IF as input source for a new JAXP transformation (a Transformer initialized with your 'transB.xsl'), and finally processes the transformed 'out.if' and renders it to PDF. Just yell if you want to try this and need assistance. Come to think of it, I don't immediately see why we don't have a Java example yet that demonstrates this. Am I missing something? If that were the case, you could probably almost copy-paste the example code and be on your way. Right now, it still requires combining a few of the examples, and a bit of imagination. IIC, it should be possible to achieve this without even storing the IF as a physical file and just chain the ContentHandlers (which eliminates serializing and reparsing the IF altogether). Obviously, you still want to allow dumping both IF files in case the chain needs to be debugged... <snip /> > Because IF is XML, it should be possible, am I right? Very right indeed. > Question is, how effective it could be, when Saxon, I guess, uses different > internal representation of XML (TinyTree) than FOP does (I do not have any > hints about internals of FOP). If it is handled programmatically, as suggested above, without storing the IFs as physical files, then it may require quite some memory, but could turn out to be significantly faster, as some disk I/O is avoided. Going via the command-line (if that were possible) would basically only eliminate serializing and reparsing the IF for the second transformation, and some JVM warm-ups in between. As you have to run FOP twice and Saxon once, going via the command-line requires a Java VM to be started three times. Keeping this down to one would already save you some. > P.S. I think, that it could be nice to add to the documentation step-by-step or > example how to use Saxon for XSL-T 2.0 transformation within FOP. It took me lot > of time before I found ... <snip /> Point taken, but still... One should keep in mind that FOP's _principal_ task is to render _FO_ to PDF, PS, AFP, etc. For convenience, FOP allows the user to specify the input as XML+XSLT, but delegates the task of that initial transformation (XML to FO) to the installed XSLT processor. FOP itself is agnostic of the XSLT implementation that is used at runtime, so one could argue that this is out of scope for its documentation (?) Should we perhaps add step-by-step instructions for _every_ possible XML parser and XSLT processor? Nice maybe, but I would hope not. Before you know it, people will expect us to have step-by-step instructions for every possible Java runtime, every possible OS... Also, please don't take this the wrong way, but I entered 'apache fop xslt 2.0' in Google, and the cited mail-thread on Nabble was the first hit. As an alternative suggestion, perhaps you could contribute this information to the 'HowTos' on the FOP Wiki (http://wiki.apache.org/xmlgraphics-fop/FrontPage)? That seems like an ideal place for this type of information. Not immediately FOP-related, but still very useful to know. Regards, Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
