XSL the ball and chain of FO

Reading Kris Thompson's XSL-FO... just shoot me! blog entry, echoes an internal report on FO processing that I recently produced. Well, almost...

I had an 'Ugly' section to my summary and that was focused on the tool support. And I am not just talking about rendering engines or XSL processors, I am talking about IDE support and authoring tools. As Kris touches on, bad FO is too easy to do - which is normally where you have some great tool to help you out (like a good IDE does). And although there are commercial FO authoring tools, and HP's stirling effort FOA, by the time you learn the tool you might as well have learned FO.

The scary thing about FO is its multitude of options. And knowing which option to use to get what effect is not that obvious. But combine that with all the headaches that go with XSL and you have a 'train wreck' prone feature. As I recommended in my report, stick with the FO - forget the XSL; if your app is already dealing with XML at the DOM or SAX level then treat the FO as just another XML format (as you would XHTML). With that strategy the renderers work much more effectively (mainly using less memory which speeds things up), which only leaves the black art of good FO.

Don't read this the wrong way. FO is top class. A client recently requested that the content of a FO sourced PDF document be sent in a plain text email, it was almost too easy. Just don't let the, was trendy, XSL part drag it down.