Re: FOPRunXSLTExt - Example 3 - Rotate wide block

On Sun, April 28, 2013 8:11 am, Dave Pawson wrote:
> On 27 April 2013 23:33, Tony Graham <tgraham@mentea.net> wrote:
>> See
>> http://www.w3.org/community/ppl/wiki/FOPRunXSLTExt#Example_3_-_Rotate_wide_block
...
> 1. Good example. The XSLT code might be.
>   if (block doesn't fit )
>     choose
>      when (fits x <-> y)
>       rotate (+90)

Pretty much.

> Another option on the feedback list Tony? I.e. another misfit variant.

I don't think so.  I've since added another paragraph on the wiki page
describing the example as a simplified variant on the existing #10.

> Issues.
>    What of a one dimension misfit? small height, big width, would fit when
>    rotated.
>    What of a 'won't fit, even when rotated'? E.g. width of block (image/
> SVG
>    is easiest to work with), e.g. 12 inch width, 9 inch paper?

The unmentioned 'Example 2' tries to do the same with a SVG graphic but I
get a NullPointerException when the extension function tries to make the
area tree.

>    Fallback option? Another round of try / catch?

'try/catch', as XSLT constructs, is only in XSLT 3.0.  The best you could
do in XSLT 2.0 is probably a recursive template or function that keeps
calling itself and making new area trees until the conditions are
satisfied.

If you want to put your logic above into an expression that you feed a
future XSL-FO 2.0 formatter, rather than doing the legwork in the XSLT
stylesheet as in this example, then you might as well assume that it also
has try/catch.

If you assume event handlers as per the other thread, then you can also
assume that you can make event handlers for the problem conditions and
that they'll keep firing until the formatter gets it right.

>    Should this apply to any block? Possibly limit to SVG, image, tables?
>    What about tables nested in para?

At the point where you can work out whether or not a thing fits, it's all
just reference areas and normal areas (and other area types) anyway.

I'm still of the opinion that we can't foretell every possible scenario so
shouldn't prematurely limit what can be done.  Since all that's happening
at present is that the stylesheet is tweaking the FO based on what can be
worked out from a temporarily generated area tree, there's currently no
limit to what you can do once you work out how to express it.

If you assume that this sort of thing will be sunk into the workings of a
XSL-FO 2.0 processor, I still think you'd want as few limits as possible
on what can be done.

> Solid use case though and manageable.

Simple, and real-world use cases could get more complicated quickly, but
it hints at what could be done.

My current problem is that all that's been done so far could have been
done using two stylesheets -- one to make the first area tree and the
second to make the decisions and produce the final output -- so we haven't
gained that much.  Maybe if someone could make the stylesheet that
implements requirement #1 -- decreasing font size until text fits -- then
we might be able to demonstrate a real improvement over using two
stylesheets.

Regards,


Tony.

Received on Monday, 29 April 2013 12:52:17 UTC