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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: AW: [xsl] XML to PDF (XSL:FO), B Tommie Usdin | Thread | Re: [xsl] XML to PDF (XSL:FO), Julie |
Re: [xsl] MSXML DOCTYPE error, Andrew Welch | Date | Re: [xsl] MSXML DOCTYPE error, Luke Stedman |
Month |