using xsl/fo - alternatives to Apache FO

[DarthLuch]

Would like to get feedback on a process we do, as well as suggested
alternatives.

We produce a software for the airline biz... One of the features is
take take aircraft OEM provided SGML/XML data, mix it with data from
our own application, and show a PDF print of it. We save our own data
as xml, merge it with the OEM xml data, and use a stylesheet to control
how we want it to look. We use Apache FOP to turn it into a PDF.

Functionally, it works great... It does everything we want, and we've
gotten used to the XSL coding. The problem is, the speed.... Many
times, many of these need to be printed in succession. Or, even when
just printing one at a time... The Apache FOP processer just takes long
to convert it to PDF.

My first question is... can someone suggest any alternative processors
for this purpose? I know I can search for them, but I'd like a specific
recommendation for this specified need. My preference would be one in C
or C++, only because I *think* that would make it perform faster.

I'd also welcome any feedback, in general, to what/how we do this
process.

 

[Stylus Studio]

Some general information ...

Try RenderX XEP: http://www.renderx.com/ - It's also supported in
Stylus Studio: http://www.stylusstudio.com/renderx/xep.html - we have
some design tools that might be useful for XML-to-PDF related work -
http://www.stylusstudio.com/xml_to_pdf.html

Sincerely,
The Stylus Studio Team
http://www.stylusstudio.com/

 

[Joseph Kesselman]

You might want to consider another rendering path. For example, some
folks have used XMLified versions of TeX/LaTeX markup (the earliest of
those was TeXML, but I think I've seen mention of several others), which
would then be processed into TeX or LaTeX and run through the
appropriate engines to get a PDF from that. I'm not sure whether that
would actually be any faster, but it might be worth trying for comparison.

 

[DarthLuch]

I don't suppose that you can tell me, from experience, that RenderX
performs faster that Apache FOP? I looked at it and saw it was also
developed in Java. But, I suppose I will try it...

 

[DarthLuch]

Interesting... I wish I had known of this one before doing XSL-FO
stylesheets. It seems that this rendering method is more suited to our
specified need that Apache-FO. Unfortunately it seems it will require a
"re-write" of how we do the stylesheet.

From what I see, it is developed in Perl. Does that make it inherently

faster than Apache FO, which is done in Java?
I will try this, thanks

 

[Joseph Kesselman]

Interesting... I wish I had known of this one before doing XSL-FO
stylesheets.

I'm not recommending the TeXML-like approach as necessarily being better
than going through FOP -- I haven't compared the two since about three
years ago! -- just pointing out that if you really can't find a fast
enough XSL-FO processor this might be another path to investigate.

Theoretically, FOP *ought* to be able to achieve reasonable speed. Java
is *not* always inherently slower than other languages; it depends on
what JVM you're using, whether you're paying JIT overhead every time
(rather than keeping a copy of the classes loaded), and whether the code
happens to hit one of Java's bottlenecks injudiciously. I haven't looked
at FOP in anywhere near enough detail to have any opinion re whether
it's performing as well as it possibly could.

(But debate about Java should probably be taken to a Java or
programming-language newsgroup, since it's something of a religious war.)

 

[Oleg Paraschenko]

Hello,

"""Joseph Kesselman ÐÉÓÁÌ(Á):
"""

I'm not recommending the TeXML-like approach as necessarily being
better than going through FOP -- I haven't compared the two since
about three years ago!

If you find time to compare, here are some links:

TeXML was recently updated:
http://getfo.org/texml/

Consodoc, a framework on top of TeXML is released:
http://consodoc.com/

just pointing out that if you really can't find a fast enough XSL-FO
processor this might be another path to investigate.

Meanwhile, it's possible that the problem isn't the speed of the XSL-FO
processor, but the speed of the XSLT processor (or, most likely, the
stylesheet). Therefore, changing the FO processor doesn't help.

 

[Joe Kesselman]

Meanwhile, it's possible that the problem isn't the speed of the XSL-FO
processor, but the speed of the XSLT processor (or, most likely, the
stylesheet). Therefore, changing the FO processor doesn't help.

Change "therefore" to "if so"... I'm assuming the original poster had
already checked that before asking specifically about the XSL-FO layer.

If XSLT is the bottleneck in your process, you may want to try
compiled-stylesheet solutions such as the XSLTC mode of Apache Xalan.

(This doesn't sound like the kind of problem where my first
recommendation would be a hardware assist such as the Datapower boxes,
but that depends in part on just how many of these you're churning through.)

 

[Peter Flynn]

Would like to get feedback on a process we do, as well as suggested
alternatives.

We produce a software for the airline biz... One of the features is
take take aircraft OEM provided SGML/XML data, mix it with data from
our own application, and show a PDF print of it. We save our own data
as xml, merge it with the OEM xml data, and use a stylesheet to control
how we want it to look. We use Apache FOP to turn it into a PDF.

Functionally, it works great... It does everything we want, and we've
gotten used to the XSL coding. The problem is, the speed.... Many
times, many of these need to be printed in succession. Or, even when
just printing one at a time... The Apache FOP processer just takes long
to convert it to PDF.

My first question is... can someone suggest any alternative processors
for this purpose? I know I can search for them, but I'd like a specific
recommendation for this specified need. My preference would be one in C
or C++, only because I *think* that would make it perform faster.

I use XSLT to generate LaTeX code from XML text, and then run pdfLaTeX
to produce PDF. I find this is faster, easier to program, and produces
better quality typography than any of the XSL:FO methods.

///Peter