- From: Tony Graham <tgraham@mentea.net>
- Date: Mon, 29 Apr 2013 13:51:52 +0100 (IST)
- To: public-ppl@w3.org
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