Print page layout and composition is an inherently difficult problem and
XSL-FO is not, by itself, up to the task where the layout rules require
knowledge of where things fall relative to other things. That means that
many layout requirements can only be satisfied by a multi-pass process that
operates on some intermediate result of the previous pass, whether it's a
proprietary intermediate format such as XEP and XSL Formatter generate, or
on the PDF produced by the first step.
This is an architectural limitation of FO that allows you to have lights-out
processing and a variety of implementation approaches that don't mandate
either an intermediate format or some sort of "feedback API".
And even when you do have feedback, implementing the correct behavior can be
very difficult. I remember trying to get automatic placement of stacked side
floats to work in 3B2 and realized that it would get into a loop where
trying to place a float on one page failed, so it placed it on the next,
which then changed the page contents allowing room for the float, which
moved back.... Very ugly. I'm sure there was a algorithmic solution to the
problem, but 3B2 had not solved it by the time I abandoned that project (not
for that reason).
Tools like Typefi use sophisticated huerstics and many passes to automate
layout with tools like InDesign, but the engineering behind Typefi is pretty
staggering and I wouldn't think of trying to replicate it, at least not
without heavy financial backing.
So Kevin's approach turns out to be a pretty reasonable compromise between a
pure standards approach and a fully-proprietary system like Typefi+InDesign.
Cheers,
Eliot
On 9/15/11 4:53 PM, "Brian Popp" <bpopp(_at_)bpopp(_dot_)net> wrote:
Wait ... I thought you were writing your own XSL-FO stylesheets and
not using another "XSL translation to FO", perhaps one off-the-shelf
That would imply the need for two passes as you suggest. But all
of your questions suggest this is not the case.
Sorry, I should have elaborated more on what I'm doing. I've used
topic and domain specialization to add several elements to DITA. I'm
processing that DITA content using the DITA/OT. Using the hooks that
DITA/OT provides, I've created XSL templates for all my specialized
content to create FO and HTML. DITA/OT gives you the ability to both
override existing templates and to create new ones.
So yes, I can write my own translations. My reasoning for thinking I
would need to preprocess the XSL is that I am going to need a rule
like I mentioned before:
<template match="entry[position()=1 and ( . |
following-sibling::entry)//limit/@origin = 'fdx' ]">
I assumed that the input file would need to already have that extra
first column added before this rule executes. I hadn't really
considered it until I read Eliot's preprocess solution, but I could
customize DITA/OT's table handling templates to add the extra column,
and then use a mode attribute with the match above to keep it from
matching until the table had been modified.
I'm a little embarrassed to say that the complexity of this solution
makes me a little uneasy, though. I don't doubt it would work.. I just
worry about it's long-term viability (both for me and for my eventual
successor) . Believe me, I've done my share of hacking (and then
some), but it usually comes back to bite me at some point.
Unfortunately I guess hacking is kind of a forgone conclusion at this
point. Kevin's XEP solution
(http://tech.groups.yahoo.com/group/dita-users/message/24049) was one
of the coolest and, at the same time, most terrifying things I've read
in a while. :)
Really appreciate all the ideas, guys. This has been a very fun exercise.
-bpopp
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--