Re: Adapt Saxon-CE event model to XSL-FO?

On 04/17/2013 09:54 AM, Tony Graham wrote:
> (I first wrote this as a blog post for my personal blog just so it can
> show signs of life.)
>
> I've been reading about how Saxon-CE [1] handles user input, and I'm now
> wondering whether the same sort of pattern could be adapted to handling
> feedback from the XSL formatter.  Saxon-CE does it [2] through template
> rules that match the element that receives the event and are in a mode
> that reflects the type of event, and similarly an XSL formatter could
> trigger on exceptional events such as overflow occurring or even on
> mundane events such as completion of a page sequence, and the templates in
> the corresponding modes could match on either FOs in the FO tree or areas
> in the area tree.
>
> The XSL-FO 2.0 Requirements [3] document includes, among others,
> requirements for: feedback from the pagination stage [4]; including
> information from formatting time [5]; and outputting the result of an
> expression [6] back into the area tree.  However, the XML Print and Page
> Layout Working Group never got to the point of working out how any of
> those would be expressed.
>
> More recently, we, the 'ppl', have been collecting examples where feedback
> from the formatter is useful [7] – or essential – for a satisfactory
> result.  Thanks to Arved we also have a proof-of-concept [8] for running a
> XSL formatter from a XSLT extension function to get an area tree, so an
> XSLT stylesheet can now make decisions about what to put in the result
> based on the trial formatted size of areas, but as it's only a
> proof-of-concept, it doesn't aim as high as getting feedback from or
> modifying in-situ the area tree for the final, formatted document.
>
> Once people have tried a few things with getting feedback from the XSL
> formatter and start asking their vendors for the same or better, they'll
> also be wanting an interoperable way to express what to do with that
> feedback.  For simple feedback of static area trees, which is all that is
> possible with the current proof-of-concept, the most interoperability that
> you could manage would be a common representation of area trees (with
> flexibility for vendor extensions) and, possibly, a library of XSLT
> functions to make it easier to navigate the area trees, but for "live"
> feedback, something more would be required.
>
[ SNIP ]

Very interesting post, I am *still* digesting it. :-)

You're quite right about our first POC: it allows for some pretty simple 
XSLT logic perhaps in a second pass, but without more direct access to 
the guts of the formatter (through a standardized API) you're not going 
to do more than that.

I have to confess, I am sort of looking at this approach, it's what I 
was talking about at the beginning.

Arved

Received on Friday, 19 April 2013 21:46:43 UTC