XSL-FO is a terrific technology for creating paginated print versions of information contained in XML documents, but it is only one ingredient in the overall information-publishing recipe. Deciding whether XSL-FO suits your needs and choosing which XSL-FO tools to use are first steps toward implementing applications of XSL-FO.
Tip
If you already have information stored in XML that you need to publish and an XSL-FO toolkit you’re comfortable with, you might want to go on to the next chapter.
Individuals and organizations who need print output from computer-based content have many choices. Typically, these range from basic text editors through to high-end word processors available to most, via office suites. The high end of non-specialist tools is probably a desktop publishing package available for a few hundred dollars. This stretches the capabilities of the casual user, introducing concepts not available to word processor users. Within this toolset, the quality of output is generally sufficient for a large percentage of the documents that we see. Nevertheless, these tools have several important drawbacks.
The limits appear rapidly as the importance of volume, print quality, layout options, repeatability, and document organization increases. Within each of these areas, the effort needed to attain a desired output increases as more features are sought. When these limits are reached, organizations either outsource the work to professional printers or bring skills and an appropriate toolset in-house. The deciding factors vary between documents, users, financial limitations, the frequency of need, and accurate growth forecasts.
One key aspect of this decision — perhaps a sign that XSL-FO is appropriate — is whether repeatability is an issue. When a document is produced regularly, it becomes familiar in certain ways; its look and feel become recognizable. We may not be able to say exactly what those elements are, but if the magazine, report, or manual fails to align with style expectations, it is noticed. The content changes with each new issue, but the house style becomes established. In some cases, the house style is dictated by simple description: “The editorial cannot be more than 200 words.” “We always have Anne’s piece here.” This repeatability and regularity form a key to processing and begin to drive input needs.
If you regularly read a report or newspaper, you begin to know what to expect where. This is one aspect of style as it applies to document preparation.
Styles need to be flexible, however. A common example of necessary flexibility is media creep. Someone may want to add another medium. A print document is no longer adequate, and the toolset that has been good enough for a print media is suddenly required to produce a web version, a version on compact disk, or an alternative media accessible to nonprint users. This brings a critical question. Do we ask our present toolkit to produce this? Often, the answer should be no, though it may take a long time to come to this realization. Tools designed for one media show their heritage when applied to other media.
XSL-FO fits in with types of document preparation in-house. Eventually, old-fashioned preparation of documents will no longer be satisfactory and the tools being used will no longer fit the bill. There are many options for improved document preparation. Among the many options is XSL-FO.
The starting point for XSL-FO is the availability of source material marked up in XML. So one of the fundamental questions is why bother with XML? Let’s consider the alternatives, making the assumption that the information will be available electronically. Data sources of interest (electronic text, either derived or originally authored) tend to reside in one of two forms: on a database or as a document derived from direct human effort. The former is just as easy to extract into XML as it is in any other format. A typical waste of effort, time, and money is to deliver information from a database in print form, then to retype it for presentation in another format.
Information sourced from a contributor is a difficult task for the system administrator because of its format. The author naturally prefers to see what she is giving, thus, the use of the What You See Is What You Get (WYSIWYG) word processor. Why should she change? What are the benefits? To answer this, I ask you to consider the costs of document preparation and manipulation. The critical costs lie in document transformation from WYSIWYG to the separation of content and style.
There is a substantial psychological barrier in any move away from direct preparation of visually styled material to the separation of content from style. This is often harder to overcome than many technical barriers. Any shift to XML-based processing at the author level will be at least as disruptive as changing between word processors, although some XML editors are emerging that appear to the user as a conventional word processor while producing XML. The business case for using XML is hard to make without case histories, few of which are openly documented. There are also tools that attempt to transform word processor formats to XML, with mixed success.
Choosing when to use XML can be difficult, but there are some rough guidelines. My organization, the Royal National Institute for the Blind, addressed this with research into the issue of multimedia production, concluding that XML is cost-beneficial for cases where more than one media is involved (statistically for greater than 1.6 media). Single-media production (just print, web, or audio) has a greater overhead when XML is used. Extrapolating from that, it may be reasonable that single-purpose documents should be produced for the target media. The only factor countering this is the lifespan of a document. For documents that may have alternate uses in the future (you define an appropriate lifespan for your use), can you risk using a proprietary format? Again, ask what is the value of the information contained within the document to your organization and if it will be used again.
When you create selection criteria, you should address the following questions. Is XML input available? What access do you have to expertise in any of these areas? What access do you have to other organizations that have chosen that particular path, and how well do their needs match yours? Is expertise available locally, or can you afford to import it? What are the timescales of the investment: are you expecting to use this toolset for a significant period or simply to meet a short term need? What payback period are you allowed for such an investment? If a particular toolset is used, how will it fit in with other tools and technology that you already use? Are your print processes isolated or part of a larger publishing process? Will you fully own the process, or will some elements be outsourced, for instance, initial markup or final printing? If so, are the interfaces known and understood? What transformations (if any) are required as part of this process? For any particular toolchain, is there a good match with the personnel involved? How readily will they accept the new tools and the associated training? Is training readily available?
Your particular answers to these questions are first steps toward addressing print production concerns.
So when is XSL-FO a good choice? What can it provide that other
tools can’t? The primary benefit is its place as an XML language that
enables the use of the increasing number of XML tools. XSL-FO takes
XML as its input, and delivers print, today most commonly in Adobe’s
Portable Document Format (PDF) or PostScript. Microsoft’s Rich Text
Format (RTF) is also being targeted as a final form, with two
implementations available. In between XML input and print is an
intermediate document in the fo
namespace. Future implementations may indeed provide other delivery
forms as an endpoint in an XML-based toolchain in today’s
organizations. The FO vocabulary is primarily for the implementors
and, in the future, may even become an invisible stage (to the end
user) as more graphical tools become available.
XSL-FO has natural allies in XSLT and XPath, which were developed with XSL-FO. These two are widely implemented and perform the content selection that is a part of the final form generation. The combined power of these is enormous and still under-appreciated.
XSL-FO is often described as a document layout language. I am a little unsure if this is intended as a perceived limitation; I certainly don’t see it this way. It is well recognized that there is a heavy investment of time and energy in the initial stylesheet design, which applies to both single-sheet output and to a full book-length document of many hundreds of pages. With careful design and good use of shared code, many documents can share the development costs.
My personal experience points to a number of variables that will support the selection of XSL-FO as a tool in the production process:
The XML is valid to a well-understood schema (or DTD).
The schema itself changes slowly (the stylesheets will need to keep up with those changes).
Content selection criteria are known in advance.
The document format is easily repeatable.
Automation is desirable.
Update frequency of the source document is known in advance.
Validation can be performed prior to processing.
Necessary character sets are available on selected processor, to avoid the surprise of producing output with missing glyphs.
Human checking of the final form is not essential. Time spent reviewing final output is not adding process value. Once stable, the production process must be trusted.
There are also some warning signs to consider before using XSL-FO. These could include:
Only well-formed data is available (no validation). To process this, the stylesheet author has to guess what might be coming.
Original authors are not XML aware.
Information comes from multiple sources (differing authoring environments that need further collation and transformation).
Content structure is highly variable.
Character sets of source material are highly variable.
I hope that these might help you review the options.
If not XSL-FO, then what? Direct competition is fairly limited. Document Style Semantics and Specification Language (DSSSL) falls into this category — it’s an ISO standard, has a moderate following, and formats XML as well as SGML. XSL-FO in its very brief history already beats DSSSL in terms of number of implementations. Less direct competition includes TEX and LATEX. These tools are more than capable of quality production and have a very active following and strong development. They satisfy many needs in the academic world, especially in the areas of mathematics formatting. More well known are desktop publishing packages ranging from packages under $100 through packages such as QuarkXPress, which is capable of producing high-quality color productions satisfying the most fastidious production needs. It is becoming more possible to get XML into and out of these systems, though it remains a considerable task.
Each alternative has its strengths and weaknesses. Solutions that hint at a combination usage are appearing slowly. An ideal would be automated processing for the majority, with “finishing” within such an environment by a professional. This is not yet generally feasible at the time of this writing. The professional printer will likely find something to complain about in all but the simplest XSL-FO document output. This is simply a realization that machines are not as good alone as with their users, which is hardly startling. Today’s processors don’t make it easy to adjust final output. While it is possible, it often requires that the stylesheet or content be adjusted to produce the desired result. It may take a period of tweaking to produce a stable final automated processing system.
Choosing XSL-FO processors is still difficult. Although work on some of the processors has been underway for years, the Recommendation only became final in December 2001 and there were substantial changes along the way. You’ll want to inspect tools closely and try them out if possible.
If, for example, you already use the Epic editor and wish to produce output using XSL-FO, that could be the perfect choice. If your present processes leave you more room for choice, know which criteria must be met, should be met, and what are nice to have?
Next, ask yourself a few questions to further narrow the selection. What expertise do you have to apply? What level of support do you need from the supplier? What development options do you want, perhaps extending the formatter to account for your peculiar needs? Are you in a position to take what’s given and use it within today’s performance envelope? How simple are your needs?
The more straightforward your print requirements the wider your choice. Are you in a position to use one of the open source developments, adding to that formatter as your needs dictate? If you don’t have the expertise in-house, might you buy it? The number of proficient stylesheet authors around the globe is unlikely to exceed the low hundreds and their availability for an in-house contract is questionable. Will remote support satisfy your needs? Can you negotiate a contract that includes updates for the initial period while the specification settles and interpretations are made public? These products are not necessarily complete yet. You will need someone capable of assessing each update.
The following sections discuss a couple of further issues to consider in detail.
Price is always a primary determining factor. Whose money are you spending: your own, your employer’s, or your clients'? There are currently three commercial implementations with support. These are the most complete implementations. More partial implementations are available in open source form.
In any event, the development of a formatter is not trivial. The people involved in that work have expended a tremendous amount of effort in developing those products, so freely available or paid for, please don’t ever think of them as cheap products. On the other hand, this is not a market in which you necessarily get what you pay for. Assess the product in terms of its capability, not its price.
Most products list each formatting object and property and state their compliance with the specification. Look on the product’s web site for this compliance table and read it closely. When you encounter problems, go back to the compliance matrix and see if the features you need are implemented. If it is, what is it doing differently from the expected action? Is it clear where the difference is? Who is right and who is wrong?
The deep and dark corners of the specification will continue to hide surprises for both implementors and the Working Group for some time to come. Having said that, I’m still confident that XSL-FO has a bright future. Its timing is right, meeting a pressing need in many areas of commerce and publishing.
Fitting a formatter into a new or existing process is not easy. If your requirements are for an automated process with minimal operator intervention, this will limit your choice to a formatter that doesn’t involve programming. If you are satisfied with a manual step carried out at less frequent intervals, with an operator manually creating the finished document, your needs meet with today’s processors. All processors provide this, with some having hooks to drive the processor from a programmatic interface. Because this is a relatively new technology, it is worthwhile to check regularly that you have the most recent version, due to the rate of change of implemented features.
PassiveTEX and UFO require a TEX installation. If this is a present part of your process, you may be pulled in that direction. If not, then be warned: TEX is not a system that can be installed and forgotten. It has a very proud history, a wide following and is extremely capable. It’s not for the faint hearted though. Watching a TEX installation makes a major office installation look trifling. What you gain, however, is wonderous to behold!
FOP and RenderX require a Java™ installation, available on most platforms. Antenna House is a standalone product, needing the least ancilliary support and system resources. Appendix C describes these tools in greater detail.
Make sure the formatter is comfortable on your target platform. Today’s formatters are not of the instant variety. For a typical chapter length file, perhaps 10 to 100 kilobytes in size, expect single figure seconds or more to convert from an XML source to output format. This puts the technology into the borderline category for instant online delivery. With smaller files, this is reasonable, but for larger files it becomes embarrassing waiting for output. You shouldn’t expect the sort of subsecond performance that you see with XSLT engines.
Tip
Performance problems in FO formatters are a situational problem. The processing of XML source documents to final form is inadvisable for online processing. Typically a three-page document can take up to 10 seconds or more depending on content, which is perceived (rightly) as an unacceptable delay for direct download. This limitation may change as experience is gained in engine design, but is likely to remain for some time. This mandates pre-preprocessing content and web updating, which is worth some serious consideration. Error handling raises the stakes.
Future developments are likely to extend the range of the final-form output of XSL-FO processors. Likely output formats include:
I hope that this list will fill out over time. For more details on particular tools currently available, see Appendix C. Remember that your situation may matter as much as the particular features of any given tool.
Like all other technologies, the success or failure of XSL-FO will be determined by user uptake and demand, implementation response to that demand, and so on. A recent development that I found hopeful was the start of work on more than one implementation of XSL-FO with RTF format being the target. Because Microsoft Word is so widely in use, the availability of that specific format has potential importance in terms of numbers and interest — perhaps not in the commercial sphere, but more in the home or office environment. I have no idea what will be the make or break points in the development of XSL-FO, but the option to produce Word documents for the office environment could be one of those.
The present focus of using PDF as the deliverable format is pragmatic. PDF is one of a small number of formats that has been widely deployed, is readily available, is well known and has the capability of browser integration for web delivery. Whether future implementations will maintain that pragmatic focus, I don’t know, but alternatives are not abundant. Few, if any, typesetting languages have been opened up to exploitation in this field, perhaps with the exception of TEX, with its target of electronic typesetting. Perhaps the advent of electronic paper (rewritable sheets of a plastic) will be a natural media for XSL-FO.
The need for paper-based delivery is, today, not in question. How that will be achieved in a multimedia-capable organization in a few years is still open to debate. Will XSL-FO be a preferred part of the delivery chain? What will help and hinder in making that choice? Tool availability, yes. Familiarity or access to the skills to develop the stylesheets? Yes, or maybe not. If the sort of visual tool that allows me to paint styles onto content becomes available, it should be possible to autogenerate the bulk of a stylesheet. Whether the impetus will be felt to develop such a tool depends on whether there’s a market for it. One of the fascinating developments in the history of XSL is transformation. Once it became known that XSLT and XPath could produce HTML from XML, that swiftly overtook the original intention. Such a twist of fate has surprising impact. What other factors are likely to move XSL-FO into widespread use? Support networks? XSLT is extremely well supported via the Mulberrytech mailing list. One of the XML Usenet groups just about splits evenly between XML and XSLT. XSL-FO has a single, quiet list. Newsworthiness? XSL-FO is nowhere near as sexy as XML (either that or it doesn’t have the support of people who are good at hyping a technology), which could influence its fate. We are unlikely to see XSL-FO streams in the mainstream conferences unless someone does some serious marketing.
Still, XSL-FO solves the problem of converting XML to print quite nicely.
Get XSL-FO now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
