On Jun 4, 2008, at 12:36, Martin Edge wrote:
Hi Martin
<snip />
When printing, each individual document is tracked via the barcode
that I
print - and which case I need to (after FOP has decided what fits
into what
page) rewrite the barcode place holders with the correct
configuration for
the Document/Page number. Thus why my current work exists in the
Intermediate Format phase.
So - is it possible given my scenario to apply what you've said (or
any
similar templating feature) at the FO or XSLT or Saxon phase?
Not really at those points in the process, if I understand your
question and description of the setup correctly.
The complete process would still look like:
XML + XSLT -> FO
-> initial Area Tree + XSLT
-> modified Area Tree
-> PDF/PS/PCL
The main point was that the modification of the initial area tree is
probably best done by means of another stylesheet. It's the easiest
way to manipulate semantic XML, and as demonstrated, requires
relatively little extra coding. The amount of extra work is
determined by how much you actually need to change in the initial
result. Saxon should have no problem transforming your 800MB area
tree, although it will obviously take time...
I'm not too familiar with the idioms for chaining such
transformations in .NET, but I know for a fact that the above can be
implemented in Java without writing intermediate files to disk or
having the entire intermediate documents in memory. The fact that
you're using a mixture of .NET and a Java application may complicate
things here, but I'm thinking:
1) XML + XSLT -> FO (using Saxon)
2) FO -> initial Area Tree (using FOP)
3) initial Area Tree + XSLT -> modified Area Tree (using Saxon)
4) modified Area Tree -> PDF/PS/PCL (using FOP)
In theory, if you use Saxon for Java, all those steps can be handled
in the same Java VM session by writing a small custom Java wrapper.
For hints on how to go about that, see the example-code on the
website: such a wrapper would look a lot like a mixture of the sample
code for using the IF and ExampleXML2PDF(*).
The output emitted by Saxon's Transformer can immediately be piped
through to FOP for the initial rendering (see ExampleXML2PDF: you
would need MimeConstants.MIME_FOP_AREA_TREE instead of
MimeConstants.MIME_PDF)
Analogously, the OutputStream --which does not necessarily have to be
FileOutputStream-- passed to FOP's Renderer for the initial rendering
can serve as the Source for another Transformer which is associated
with the second stylesheet. Finally, the Result of that transform
would in turn be used as a Source for FOP's AreaTreeParser for the
final rendering.
This could avoid writing the FO or area trees to disk, and eliminates
the cost of multiple JVM warmups that you're stuck with if you call
out to FOP multiple times using the console from within your .NET
application (if this is how you currently handle it?). You would
instead call out only once, to the custom wrapper application. To go
even further, the wrapper could be set up as a web-service, which
would make it possible to use cached Templates (parsing the
stylesheets only once), and avoid JVM warmup for all but the very
first run. Calling out to the console would then be replaced by
sending an HTTP request to whatever server:port hosts the service.
Of course, this is a rather simplistic sketch, which may raise more
questions than it answers, and I have no idea where the initial XML
and XSLT (XSL-FO) in your setup come from. If they exist as files on
disk somewhere, the above could be relatively simple to implement. If
they're only exposed to you as .NET objects, that would obviously
make it more complicated.
(*) http://xmlgraphics.apache.org/fop/0.95/intermediate.html#usage
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/
embedding/java/embedding/ExampleXML2PDF.java?view=markup
HTH!
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
