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

On Wed, April 17, 2013 2:52 pm, Dave Pawson wrote:
...
> On 17 April 2013 13:54, Tony Graham <tgraham@mentea.net> wrote:
...
>> Applying the Saxon-CE approach to XSL-FO, the following illustrative FO
>> event handler would handle a figure overflowing its available space by
>> reducing its size to 80% of the current.
>>
>> <xsl:template match="BlockArea[key('fig', @id, $src-doc)]"
>>               mode="ppl:overflow">
>>   <xsl:result-document href="#{@id}/area:external-graphic"
>>                        method="replace-content">
>>     <xsl:copy>
>>       <xsl:apply-templates select="@*"/>
>>       <xsl:attribute name="width"
>>                      select="ppl:scale(area:external-graphic/@width,
>>                                        0.8)"/>
>>       <xsl:apply-templates/>
>>     </xsl:copy>
>>   </xsl:result-document>
>> </xsl:template>
>
> 1. It seems a solid, aligned way of managing feedback.
> 2. I like using xslt syntax.

As the post said, the advantage is that (most) users wouldn't need to
learn a new language.

> 3. How to generalise it? E.g. an area overflow could be one of many?
>     over a column, table cell, page ....

I'm not sure that I understand.  The @match specifies what the event
handler applies to, and presumably the usual XSLT rules about template
priority (including use of @priority) would apply.

If this takes off, I would also expect more appearances of @role [1] and
@id [2] in FO documents just so it's easier to write event handler @match
attributes.

The question of which event handler to 'fire' if there are multiple
applicable event handlers with the same template priority would have to be
decided (ideally by experience after trying it out rather than by deciding
in email now), but my current expectation is that the XSL formatter/XSLT
processor combination would start with the lowest level area applicable to
the event (e.g., the lowest level fo:block in a fo:block-container that
overflows) and, in effect, look up the 'ancestor' axis of the areas until
there's an applicable event handle defined.  I have no firm opinion on
whether it should first look only in the FO tree or only in the area tree
or alternate between the two at each level.

You could also postulate a more callback-like approach where you specify
the event handler name(s) in the value of a new FO property, or postulate
a new property to specify whether to look in the FO tree or area tree for
event handlers in the event of an event.

What happens when, e.g., multiple cells in a table row would each cause
the table row to split and there's an event type and event handlers
defined for that sort of event is anybody's guess at this point.

> Thinks. Is it possible to categorise 'events' and provide options?

I think someone gets to invent the event types and, hopefully, multiple
people get to implement them.  Any list of event types would probably
include 'overflow' and 'intrusion', but there's bound to be others.

>  E.g. an overflow event, could I be 'pushed' into using a choose
> with only a number of options?

As described, you get to write XSLT.  What that does is up to you.

>     Blow up | report error

<xsl:message terminate="yes">

>     Reduce the item to fit (somehow)

Rewrite properties in the FO tree, and when the event handler finishes
running, the XSL formatter gets to reformat the modified FOs and then
adjust the rest of the formatted document based on how the areas changed.

So another part of event handling by the XSL formatter is determining
which event to handle first, since you don't want to first handle an
overflow on the last page if the next event handler to run is for an
overflow on the first page and that event handler changes the areas such
that the overflow on the last page no longer occurs anyway.

>    wrap onto the next block/line?

Rewrite the applicable FOs in the FO tree or rewrite the area tree, it
would be up to you.

>    truncate / trim the fo?

Rewrite the applicable FOs.

As with Saxon-CE [3], xsl:result-document would be used to address parts
of the existing document to modify.  I don't know how an area tree event
handler would select to modify the FO tree, and vice-versa, but it could
be as simple as inventing two bogus 'x-fo' and 'x-area' URL schemes.

>>   <xsl:result-document href="x-area:#{@id}/area:external-graphic"
>>                        method="ppl:replace-content">

> so that the formatter is still in control of formatting, the user is
> selecting
> from sensible options?

You would hope so, but it would probably also present opportunities for
event handlers, or sequences of event handlers, to go into endless loops
making and unmaking the same adjustments.

> For me this is much more like an xsl-fo solution.

What is much more like an XSL-FO solution?

Regards,


Tony.

[1] http://www.w3.org/TR/xsl11/#role
[2] http://www.w3.org/TR/xsl11/#id
[3]
http://www.saxonica.com/ce/user-doc/1.1/index.html#!coding/result-documents

Received on Thursday, 18 April 2013 13:26:48 UTC