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

On 19 April 2013 14:17, Tony Graham <tgraham@mentea.net> wrote:
> On Thu, April 18, 2013 3:02 pm, Dave Pawson wrote:
> ...
>>>> On 17 April 2013 13:54, Tony Graham <tgraham@mentea.net> wrote:
> ...
>>>>> <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>
> ...
>
>> Issues (possible, if I guess right).
>> One event per match? Hundreds of match strings?
>
> XSLT 2.0 allows multiple tokens in xsl:template/@mode and multiple
> alternatives in xsl:template/@match, so there's scope for templates that
> are usable in multiple contexts.

I was asking how many matches you envisaged rather than xslt
capability. A limited number seems workable, dozens/hundreds
seems unworkable to me?



>>> 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.
>>
>> So do you see the @match being to source document attributes?
>>   ... I was thinking of 'matching' (wrong word) on formatter events?
>
> @match would contain XPaths that would be matched against contexts in
> either the FO tree or the area tree.  The formatter events would be
> represented by @mode tokens.

In which case you've lost me Tony?


>
> The original source XML document(s) might or might not be available, I
> don't know.

I assumed not, i.e. only the xsl-fo XML was available to the formatter.



>
> If you went the callback route, it could be something like:
>
> <fo:block ppl:callback="name-of-a-template">
>    ...
> </fo:block>
>
> or even:
>
> <fo:block ppl:callback="ppl:overflow my-overflow template ppl:intrusion
> my-intrusion-template">
>    ...
> </fo:block>
>
> but both alternatives seem like more work to write and to maintain than
> letting the formatter work things out as in the original proposal.

I agree... bit like saying, for every block of text, 'if this goes wrong'.....
 I.e. not workable, unless iterating round an edit/test cycle?


>
>>> 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.
>>    Does your 'ripple up the source tree ' model work here?
>>    As with the list above?
>>>
>>>> Thinks. Is it possible to categorise 'events' and provide options?
>
> The type of the event becomes the mode name.

I'd appreciate more description on this? I don't see how this might work.



>
>>> 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.
>>
>> Yikes. Good point. First page to last, bottom to top?
>> Something like that?
>
> Probably, though I'm not sure if you mean bottom of the tree or bottom of
> the page.

<grin/> Neither! bottom to top of the fo tree was my thought, least
area to entire document?


> It would be good if a formatter could stop if it finds itself in an
> endless loop, just as your XSLT processors do now, but I don't think
> anyone could legislate against, or a processor recognise in advance, all
> the ways that it's possible to make an endless loop.

True, might be worthwhile recognising this fact.

regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

Received on Friday, 19 April 2013 14:39:05 UTC