Re: [xsl] Quality between XSL:FO PDF and InDesign PDF

[Tony Graham <Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx>]

On Sun, Apr 25 2010 02:51:04 +0100, hoskgret@xxxxxxxxxxxxxxxx wrote:
> [Peter Stoll's question]
> HI, without trying to respond to the other comments about InDesign and
> PDF (and trying not to violate the spirit of the xl-list), here is my
> opinion based on my work with XML in InDesign: If you need to generate
> PDF, and that is you major criteria for output, then the difference is
> whether you need to be able to make full-scale aesthetic adjustments
> on the output, or whether an automated, template-driven output will
> meet your needs.
> Adobe  InDesign is the only high-end graphic design application on the
> market that will permit mixing non-XML and XML content in the same
> document, with different column layouts on any page, have complete
> typographic control and will produce PDFs that are suitable for offset
> printing color separations. It will compose pages in appropriate
> imposition pairs, although you will need other software to make
> complete press-ready signature imposition. You use InDesign typically
> because the paper printing process defines the space that you MUST
> publish within, whatever your defined page size, and you can't add
> pages if the text runs longer that what will fit in your
> design. Balancing all these advantages is the fact that it is a poor

It's true that the XSL FO spec doesn't say anything about fitting the
formatted output to fill a certain number of signatures.  I'm currently
reading "Book Typography: A Designer's Manual" [1], and it says rather
more about making extent (three chapters) than does the XSL 1.1 Rec.

As you say, the model for XSL 1.1 has been "lights out", with the
formatter making as many pages as it takes.  One of the advantages of
that is that it allowed XSL FO support to be retrofitted to some
existing formatters at a time when there were no native XSL formatters
available.  The requirements for XSL 2.0 adds rather more feedback
between tho area tree and the FO tree [2], so it would be harder to
retrofit XSL FO 2.0 requirements onto an existing formatter.

However, it remains possible to write a XSL formatter that does care
about extent and signatures, though at this point how to specify that
would have to be non-standard.  You could also support interactive
fix-up after the initial formatting run, though feeding that back into
the source XML is not an easy problem since you might, for example, want
to manually kern between two characters where one came from the source
XML and the other came from the stylesheet.

> XML editing application. You are likely to need to simplify the XML
> structure to map it to paragraph and character styles, and it's very
> difficult to develop true round-tripping back to the original XML.

As stated above, round-tripping from an interactive XSL formatter also
wouldn't be easy.

Regards,


Tony Graham                         Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx
Director                                  W3C XSL FO SG Invited Expert
Menteith Consulting Ltd                               XML Guild member
XML, XSL and XSLT consulting, programming and training
Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
Registered in Ireland - No. 428599   http://www.menteithconsulting.com
  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
xmlroff XSL Formatter                               http://xmlroff.org
xslide Emacs mode                  http://www.menteith.com/wiki/xslide
Unicode: A Primer                               urn:isbn:0-7645-4625-2


[1] http://www.libanuspress.co.uk/
    A good book despite the cover photo looking like a salmon fillet
[2] http://www.xmlprague.cz/2010/sessions.html#What-XSL-2.0-means-for-implementers-and-users