Sometimes you need to transform your HTML into something that looks good on a printed page. For such needs, there's XSL Formatting Objects, or XSL-FO.

Whereas Cascading Style Sheets and various HTML or XHTML transformations handle XML transforms for content display inside a Web browser, when such pages are printed, they seldom look as good on paper as they do on screen (nor, in all fairness, are they designed to handle this kind of thing).

In a nutshell, XSL-FO is designed specifically to take XML format and by applying a specific stylesheet and well-defined transformations, to make content look good in print (at least, within the limits of the stylesheet designer's abilities).

Apache FOP, Render X's XEP and Altova's Stylesheet 2005 are three of the main tools that provide XSL-FO rendering capabilities.

"To access this tip, you must first be a registered user of SearchWebServices.com or another site in the TechTarget network."

The tip just tells what XSL-FO is and points to a number of resources, several of them commercial. Since XSL-FO is hardly something new (I think it has at least 3 years), it is too basic for a tip.

I think it illustrates the fact that XSL-FO has been a failure, since for whatever reason it has not been widely adopted. One just has to compare the little support of XSL-FO with the success of XSL-T .

I know a development house where they used Apache FOP to output PDF listings from Java web applications. Now they have switched to using iText, because of performance (FOP takes tons of memory). Also, since bare iText may lead to unmaintenable programs, they have also used another SourceForge project on top of it, UJAC, to ease this task.

Thanks for the input Javier. Nothing new there.

I do think that there is a place for some kind of generic intermediate format. And XSL-FO might get a second chance because the Eclipse BIRT project uses it as an output format.

My 2c

My own experience of using XSL-FO has been less than happy.

If you are trying to work at the XML level, which you have to when using it in conjunction with XSLT (its intended use), it is hopelessly complex.

Apache FOP, though free, does not support all image and graphics handling, and hasn't for 2 1/2 years.

My advice would be, don't use it unless you really have to, and buying decent (& expensive) visual tools will probably pay off in the long run.

Kit

Why do you say XML is hopelessly complex?

To be sure, there is a learning curve when using XML, XSLT, and XSL-FO for the the first time, but I have got very good mileage from this approach and found Apache's FOP processor quite useful.

In one application, I have a servlet that serializes an object graph as XML and then transforms it using XSL-FO into PDF or HTML formats. This allows me to reuse the same XML data for different purposes.

The learning curve for me was how to create an XSLT stylesheet for PDF generation. I have used FOP for this purpose on a number of projects to date.

My only concern is the demise of the Avalon framework project. It appears that FOP depends on a logging class from that library. I'm not sure if FOP is still active but if it is I would like to hear from the developers on their plans for the processor, in particular on removing any Avalon dependencies.

On apache FOP site is new release 0.90 alpha 1. Read more on http://xmlgraphics.apache.org/fop/relnotes.html#FOP+0.90+alpha+1
We are using Apache FOP 0.20 in our financial application. We have big problems to generate HUGE reports. Sometimes general ledger is 25.000 pages long. It's a big pain. For reports up to 1.000 pages long it's fine even for server usage.

Thanks Pavel.

Are you on the FOP development team? It's good to see the project is still active and getting closer to a 1.0 release.

Just curious, what do you think have been the biggest challenges for the FOP project over the last couple of years? What types of issues are blocking progress, eg. resources, complexity, scope, etc.?

Ian,

I have a servlet that serializes an object graph as XML

Check out org.xml.sax.XMLReader. Its pretty cool for supplying data in a transform.

Wrap your XMLReader implementation in a SAXSource, and then use that instead of a DOMSource or a StreamSource.

SAXSource s = new SAXSource(myXMLReader, new InputSource());

It bypasses serialization of data.

I also agree with those who say that XML, XPath, XSLT, XSL-FO are pretty easy once you've spent a little bit of time learning it. XSL-FO is pretty much HTML + CSS done only slightly differently anyway.

I also agree with those who say that XML, XPath, XSLT, XSL-FO are pretty easy once you've spent a little bit of time learning it. XSL-FO is pretty much HTML + CSS done only slightly differently anyway.

I have to disagree with this. Firstly, HTML/CSS define page objects whereas FO defines page flow, ie. is a set of layout instructions, a bit like RTF or MSWord. Page flows give you more control over the renderer but end up making simple jobs more complex than the equivalent page object definition.

Secondly, XML/XSLT/XPath weren't the problem. I already had those under my belt. It was when I started with FO that the problems started. Someone mentioned that page flow is complex. I completely agree and maybe some of FO's complexity just comes from that. But when you add inconsistent renderers, incomplete implementations and other non-FO-based products that do the same job much more simply, it's not a technology I can get really excited about.

Sorry. With the right project and toolset, I am sure it has been very helpful for many people, but my experience was poor. YMMV.

Regards
Kit

Hi all

I have been using Apache FOP for almost 3 years now and for my use it's been very great =)
It's not a super simple setup with XML, XSLT etc. but i really like the basic idea. XSL-FO is a standard. (Although not all rendered seem to do 100% the same job after what i hear you say.) So swapping engin should be easier to manage then with propritary API's.

About preformance i dont know what to expect, but i have been rendering maybe millions of documents with it. I am also a designer and know my way around DTP, print, images etc. Images are allways the issue when it comes to preformance and document size.

Personally i think it is a bad idea to design your documents in java etc. I can do that but my fellow designer dont want to do that. There are also comming more tools to design XSL-FO i've heard.

-Erik

There are also comming more tools to design XSL-FO i've heard.-Erik

Here's one I've used:
MS Word

I thought I read somewhere that Word may use FO natively in the future, but I'm afraid I can't track it down at the moment.

Kit

Apologies.
And the link again.

Ian,

I have a servlet that serializes an object graph as XML

Check out org.xml.sax.XMLReader. Its pretty cool for supplying data in a transform.Wrap your XMLReader implementation in a SAXSource, and then use that instead of a DOMSource or a StreamSource.SAXSource s = new SAXSource(myXMLReader, new InputSource());It bypasses serialization of data.I also agree with those who say that XML, XPath, XSLT, XSL-FO are pretty easy once you've spent a little bit of time learning it. XSL-FO is pretty much HTML + CSS done only slightly differently anyway.

Thanks for the suggestion. It would be nice to bypass the need to serialize data as XML for XSLT, but wouldn't the overhead of implementing XMLReader's 14 methods outweight the benefits of straightforward object graph serialization provided by libraries such as XStream, Castor, JSX, JAXB, etc.?

We have been using XSLT and XSLFO for 5+ years now to produce simple "on-demand" documents, as well as complicated "print ready" hi-res PDFs. I have learned is that to get good results, you need:

1. A good Renderer: XEP is our choice. The FOP moves along too slowly and XEP (and others) have gone beyond the FO standard to accomplish more complex features. This can obvisouly branch the FO standard, but right now there aren't too many other options.

2. Need a dedicated XSL skill set. I have found (again just personal experience) that good OO developers do NOT necessarily make good XSL (functional) developers.

3. Someone on the engineering team should have flow-based print background (Quark/Indesign, etc). Just like in programming, where if you know one language and you move to another language, you know what to expect in the new lang, i.e. what constructs/features should be available, you just might not know the syntax yet. Page flow is complex and there are a lot of complex concepts to deal with if you want to go beyond simple documents.

Please note, I didn't log into the TIPS site mentioned in the root post, so these might be obvious, but they are just some tips from my experience.

Thank you for your informative posting.

The company i work at is centered around document generation and FO is the main technology that is used. Has anyone tried to generating FO with XQuery ? We are thinking of moving some of our XML transformations away from XSLT but for FO generation i cant see any real advantage for using XQuery. Also how often do people use the match attribute? <xsl:template match="/data"> here and at my previous employer i have found that its only used to find the root element.

Sam

Greetz,

My first post...

We are running on Ibex from Visual Programming. Works 4 us:

http://www.xmlpdf.com/

Has a memory advantage above FOP and IText. Didnt compare it with XEP, though.

Indeed, commercial products (although not cheap!) provide a lot of bang for the buck. We are using XF from www.ecrion.com and besides having a visual editor (which helps because XSL-FO is very rich in features) is also very fast and has a lot of features like rendering page thumbnails or processing batches of thousands of documents.
I think the main advantage with XSL-FO is that (just like HTML) is a W3C standard, which means companies have to compete on equal foot to provide better products. While proprietary solutions may provide some flashy features (like "zero development effort" or reports are "magically" created from the database), you end up locked in a solution with severe limitations.

Another product, ease to use, is XML Publisher

Built-in into Oracle Applications
http://www.oracle.com/technology/products/applications/publishing/index.html

or standalone
http://www.rittman.net/archives/001385.html

Sometimes you need to transform your HTML into something that looks good on a printed page. For such needs, there's XSL Formatting Objects, or XSL-FO.

Whereas Cascading Style Sheets and various HTML or XHTML transformations handle XML transforms for content display inside a Web browser, when such pages are printed, they seldom look as good on paper as they do on screen (nor, in all fairness, are they designed to handle this kind of thing).In a nutshell, XSL-FO is designed specifically to take XML format and by applying a specific stylesheet and well-defined transformations, to make content look good in print (at least, within the limits of the stylesheet designer's abilities).

Apache FOP, Render X's XEP and Altova's Stylesheet 2005 are three of the main tools that provide XSL-FO rendering capabilities.

Just wanted to provide an example of using XSL to perform visual styling elements.

At eSigma our standards and security requirements do not allow for any client-side, or proprietary, scripting languages. In addition we require that every document must render as W3C valid document, HTML or XML-based. At the time we launched, in 2002, there weren’t examples or sites using this methodology, so it was a challenge to select the right standards and technologies when we decided to build our public consortium for Web Services. We decided to re-write our application stack using XML, XSL, and XSLT for both UI and inbound requests. The result is a standards-based interface that allows us to render, or transform, our documents into any format (PDF, PostScript, XML, HTML, XHTML, EDI, etc…), supporting any browser. In addition we are able to create a feature rich, visual web application that confirms to well-defined standards, not limited to just utlizing CSS to maintain state, and related attributes.

If anyone has a chance, check out esigma.com and let me know what you think. We are still in beta and have not officially launched our 2.0 offering. Here is a link to an example: http://www.esigma.com/resources/governance.html

We are planning on releasing an Open Source version of eSigma so that individuals and organizations can publish, consume and manage Web Services, so anyone curious can see how using XSL can provide you with the ability to add styling elements to your application.

Feed back is always welcome.