FOSI vs. XSL-FO, part II

Written by: Eliot Kimber Last Updated: 2006-08-25

XSL-FO 1.1 is fast approaching Candidate Recommendation status. You can view the latest working draft here: http://www.w3.org/TR/xsl11/ [Editor's comment by Karl Johan Kleist: this did happen 20 Feb. 2006].

1.1 adds a number of important new features, including table markers, which can be used to create "table continued" headers and footers (although I believe that, at least in the short term, Epic will continue to require the use of the FOSI float extension in order to do this).

1.1 also provides pretty complete back-of-the-book support, change bars, and multiple flows within a single page sequence, as well as a number of smaller enhancements and refinements.

In the abstract I don't think there can be any question that XSL-FO is the better choice over FOSI for the simple reason that FOSI is essentially a dead technology while FO has wider acceptance and support and, with the extensions provided by various vendors, satisfies the same composition requirements that FOSI does (that is, primarily technical documents with relatively simple layouts.

If you have requirements to compose documents in non-Western languages, especially CJK, Thai, and Hindi (Devanagari script), then FOSI is not really an option because Epic's support for these languages is either incomplete for many applications or nonexistent (Thai). This is true for pretty much any other composition technology you might try: FrameMaker, XPP, etc. If you need Thai, FO (and XSL Formatter) is pretty much your only option today.

In the context of Epic products specifically, FOSI is still attractive because it's what Epic Composer is optimized for and Epic's FO support is still not complete (in terms of useful FO features). If you have resources who can create and maintain your FOSIs then FOSI may still be the best choice, at least until Epic's FO support provides the same level of layout features and performance that its FOSI support does.

While a practical FO implementation still usually requires the use of proprietary extensions to satisfy layout requirements FO alone can't meet, this isn't that bad:


 * The W3C way is for standards to trail requirements, letting the market drive new features and then standardizing those that get significant implementation. If you look at FO 1.1 you'll see that it almost entirely reflects features that were first implemented as extensions in at least one FO 1.0 implementation. For example, both XEP and XSL Formatter had extensions to support back of the book indexes. In 1.1 we defined new index support that reflects the requirements those extensions supported and reflects what was learned in practice from both of those extensions. That will almost certainly continue to be the case going forward.


 * Because the FO instance is something you normally transform into, there's no *data* commitment to non-standard extensions, just code. In practice, the amount of code in a typical FO generation process that reflects extensions is maybe 10% of the total code (at least that's my experience in writing transforms that support both XEP and XSL Formatter as targets). Using the code modularity features of XSLT it's easy to apply standard engineering practice to further isolate the processor-specific code, minimizing the cost of using extensions.


 * There are some things FO will never standardize for the simple reason that they are outside the scope of the FO spec, such as generation of PDF-specific constructs, print job control, and so on.


 * At the end of the day, the job is getting the pages out in a way that minizes cost while providing appropriate quality. This is a job that always requires some amount of hacking and fudging. Always has and always will. The best we can do is minimize the hacks and engineer our systems to protect ourselves from our own hacks. In my analysis, for applications for which FO is otherwise suitable, FO+XSLT provides much better hack protection than any other available options.