W3C home > Mailing lists > Public > www-xsl-fo@w3.org > October 2002

RE: Using XSL-FO For Heavily-Designed Documents (e.g., magazines)

From: Ian Tindale <ian_tindale@yahoo.co.uk>
Date: Fri, 18 Oct 2002 21:30:25 +0100
To: <www-xsl-fo@w3.org>
Message-ID: <000901c276e5$32039880$fc00a8c0@solstice>

One of the notions I pontificate upon in my book on XSL-FO that I'm writing right now* is that I propose that for complex multi-story layouts, such as a local newspaper, we should identify the stories as one-per-root. That is, each story is it's own XSL-FO document from the root down. Each story shares identical layout-master-set and other pagination knowledge, and each story if printed alone would probably result in a page or two (not necessarily contiguous) of mostly blank page with a few galleys/pictures/content tucked away in some area somewhere (not necessarily rectangular, but certainly made of rectangles) (i.e. out of it's biggest area bounding box, parts will be 'blanked off' using static content of blank nature). 
The result is that you end up with several XSL-FO docs. Each has a root. Each root - each doc - should be regarded as a story, not the overall publication or document. The trick is to superimpose each page from each story. I suggest don't do this at the XSL-FO stage - no need. Do it at the PDF stage. This would need a re-write of a FO to PDF formatter, but I can envisage (in part due to the 'painter's model' used by PostScript) that it should be possible to superimpose the impositions correctly such that the final PDF or PostScript is a fully paginated fully filled set of newspaper pages, each story keeping to it's own territory, and each story having it's own identity which doesn't necessarily depend on the others.
To give an example - imagine a page divided into 6 columns. You run a story across four of those columns, but divide that area into five columns. The remaining 2 of 6 is filled with matter, but underneath the 5 of 5 bastard column block, the 2 of 6 flows into the remaining 4 of 6 to make 6 of 6 for a short while. Difficult in 'normal' XSL-FO, but using superimposed or composited XSL-FO, might be easy. 
Another thing is that I'd suggest not using the side regions. Bit of a waste of time in my opinion. I can imagine a few instances where the before and after might just come in handy for running title and folios etc, but hardly any - they're too restrictive, in that they're always stuck to one edge or another. I suggest only using the region-body, which if we composite then won't be quite so restrictive. Trying to use a full-bleed photo background into the body while also somehow trying to fit a side-region in is clumsy at best.
One thing I'd like to ponder over is whether it's worth using each picture block as a wrapper for SVG in which the picture lives. So many times I need or would like to slightly tilt a picture. It's not something that XSL-FO has taken into account. In extreme moments, I wonder if it's not probably worth it to use each and every FO object as a container for SVG which is then used as a container for the true content. Shame SVG's text wrapping is a little lacking - especially when it comes to important things like hyphenation hot zones and widow/orphan management. Shame SVG can't just 'hand over' to XSL-FO for all text management, once it's agreed what is and isn't a glyph.
Picture boxes have become an interesting and, for me, completely valid use of the table FOs (considering I'm dead against the 'architectural' use of tables in HTML). Pictures, oddly enough have not been given the same 'special treatment' that tables and lists have, as specialised structures. Never mind - it can all be done as a table. Picture, caption, photo credit, etc. 
One aspect that seems to bring a smile to people regarding XSL-FO is the notion of automatically balanced flowing columns. Probably because this is such a difficult thing to achieve in HTML. The idea of resizing the window and watching crossheads and copy and pictures reflow and find themselves again elsewhere in the right order is initially appealing. Just like a DTP designer if they resized the text box.
However, the reality is that nobody will resize the paper it's printed on, or you hope not, and that printed matter is given territory and it must fit - not under and not over, and none of this ridiculous sprouting of extra pages nobody asked for - imagine if an imagesetter did that! Thus, one paradigm of magazine design is one of tight copy fitting and exact space allocation, with no room for much error. Thus, use design skills that allow flexibility where needed, such as allowing dead space at the end of final columns as a design 'feature' (as long as there's no chance of overflow in worst case!).
Things like that.


*Don't worry Dave and Ken - my book doesn't eclipse your each quite excellent books. Mine's aimed at a slightly different audience. Its role is essentially one of appealing to people in the print industry, to publicise the concept of XSL-FO and server-bound composite publishing. Then its other role is to try and imbue XSLT people with the kind of thinking that a graphic designer would go through. In short, it's trying to fill the gap between programmers who can't design for toffee, and designers who can't even spell XML, let alone write any. 
Me? I'm an ex Art Editor of Mayfair magazine (yes, that one) and I'm trying to make XSL-FO a 'sexy' technology as it were, trying to give it a bit of PR, trying to plug it (accurately) - but without hyping it or overpromising anything.
-- 
Ian Tindale
Received on Friday, 18 October 2002 16:31:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2007 16:06:09 GMT