Re: [xsl] XML to PDF (XSL:FO)

Subject: Re: [xsl] XML to PDF (XSL:FO)
From: Eliot Kimber <ekimber@xxxxxxxxxxxx>
Date: Tue, 24 Jun 2008 09:46:20 -0500
On 6/24/08 7:59 AM, "Pankaj Chaturvedi" <pankaj.chaturvedi@xxxxxxxxx> wrote:

> Many guys are using it and even I wanted to test it of my own but somehow
> things have deviated to other developments. I was reading somewhere that
> many developers are using XSL:FO for business cards, brochure etc, but what
> about the professional publishing like books and journals (which we do most
> of the time).

XSL-FO has been primarily driven by the requirements of technical
documentation and business documents (invoices, bills, etc.), rather than
the requirements of highly-designed or typographically-sophisticated
publications (trade books, magazines, journals). Some of the FO
implementations add features that provide some typographic and layout
effects that go beyond the 1.1 standard but those are not sufficient to
handle the general requirements of books, journals, and magazines. XSL-FO
2.0, currently under development by the W3C, aims to improve FO's
typographic and layout sophistication, but it's unclear at the moment when
we can expect 2.0 to be available (wheels turn slowly for mature standards).

For that reason. In general, XSL-FO, as defined in the XSL 1.1 standard and
as implemented by the available commercial and open-source engines, is not
usually up to the task of doing production-quality typography for books and
journals, for the following reasons:

1. FO's avoidance of "layout-driven" formatting  means there are a number of
typographic and layout effects that cannot be achieved directly, but would
require at least an engine-specific multi-pass process or hand adjustment of
layout following the FO rendering process. In general, anything that
requires that two page components be positioned in a way that depends on
where on a page or within a page spread one or both elements fell, cannot be
done with XSL-FO, at least in a single pass (with a multi-pass process,
anything is potentially possible, but the FO standard does not standardize a
mechanism for feeding back output of one pass to subsequent passes, so any
such multi-pass process would be, necessarily, tied to a specific FO engine.
Both XSL Formatter and RenderX do provide intermediate formats that can and
have been used to implement multi-pass FO processes, but there is no
generally-available general solution for either product).
 
2. The FO engines have to date focused more on speed and FO feature
completeness than on typographic details, such as kerning and hyphenation,
which is consistent with the needs of their primary markets (technical
documentation and business documents). While both XSL Formatter and RenderX
have pretty good typography, neither will satisfy the high-end demands of
many Designers working for publishers.

However, I know Antenna House has or is about to introduce an InDesign INX
output option, which is specifically designed to allow for post-rendering
adjustment of pages, which is pretty interesting. I'm not sure if RenderX
has the same sort of features available or in mind.

On a publication-by-publication basis you may find that FO will work and
when it does, the economics are very compelling, with an FO-based solution
generally 1/10th the cost of any other technology option for the same level
of automation and throughput speed.

Note too that FO benefits most from repeatability, meaning publishing many
titles with the same automation process (meaning the same family of page
designs). Using FO for a one-off design doesn't usually make sense because
the cost of implementing the FO generation process is greater than the cost
of doing the typography manually in something like InDesign or QuarkXPress.
Of course, one can start to build a heavily parameterized FO process that
lowers the cost of implementing new page designs, but there is still the
issue of mapping from the input XML to the FO result--if both the XML and
the FO target will vary by title, FO loses most of its cost advantage.

However, if cost and/or throughput speed are an important business issue,
you may find that you can either compromise a bit on layout and typography
and apply FO at a much lower cost/faster turnaround or take advantage of
proprietary extensions to meet typographic requirements. But this requires a
careful, detailed analysis of the typographic and layout requirements of a
given publication to determine if FO can meet requirements.

My experience has been that there is a class of journals and trade books
that use a consistent page design for many titles or issues and for which
cost and throughput are strong enough business drivers and for which
typographic sophistication is within the range of what FO can provide. In
these cases, an FO solution can be very attractive.

For automating higher typographic quality, the Typefi product (an InDesign
plug in) offers excellent value, although it's initial cost is high (on the
order 50K USD). Likewise, you can do significant automation with Arbortext
Advanced Publisher (3B2) and XyVision XPP, but at a similar or greater cost
than Typefi.

Cheers,

Eliot 

----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@xxxxxxxxxxxx <mailto:ekimber@xxxxxxxxxxxx>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> 

Current Thread