Re: Customer requirement, a critque

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