- From: Arved Sandstrom <asandstrom2@eastlink.ca>
- Date: Thu, 07 Mar 2013 21:34:55 -0400
- To: public-ppl@w3.org
On 03/07/2013 09:33 AM, Tony Graham wrote: > On Mon, February 25, 2013 3:01 pm, Patrick Gundlach wrote: >> Am 25.02.2013 um 15:35 schrieb Jirka Kosek <jirka@kosek.cz>: >> >>> Also one can imagine extension instruction for XSLT which will invoke FO >>> rendering of a partial FO document. Based on result of formatting XSLT >>> code can then decide to throw away this result or put it into final FO >>> file. >> that sounds like a very reasonable approach to me. Thanks! > All we need now is someone to whip up a proof-of-concept extension > function for a XSLT processor that takes a tree of FO nodes and returns a > tree of area tree nodes and demonstrate it being called more than once in > one transform. > > The low-hanging fruit would probably be FOP and either Saxon or Xerces. > > Regards, > > > Tony. > > I can take a look at FOP in this regard, dunno if anyone currently associated with FOP is here and/or has the cycles to take this on. Can't say I've looked at it for years, but I deal with Java most every day, and I did work on FOP way back when. Can't say I am entirely clear on what's being described here. Maybe it's just that I've been waking up at 4 AM every day this week. :-) I have a mental model of how things usually work now: (1) run XSLT on XML and get FO, (2) run formatter on FO and get rendered PDF or whatever. Internals of formatting, including area tree, are black-box [sort of]. I said sort of, because FOP (presumably among other implementations) can output an XML representation of the area tree (or one could implement a new Renderer, which has access to the area tree). Do we want to start here, with access to FOP's area tree after a complete initial pass through the FO? If so, I understand from the language above that this entire first formatting pass is to be encapsulated in an XSLT extension function? Yes? Arved
Received on Friday, 8 March 2013 01:35:23 UTC