Re: Other paged media processing approach - summary

For me one of the biggest advantages of XSL-FO is its declarative nature. Not the authors but the spec writers and implementers have currently to do the hard work of defining and implementing the layout optimisation rules.

As pointed out in this thread, it is maybe also one of its weakest points, because the standard (or extensions (proprietary or community driven?)) has to catch up with the author/implementors requirements, and implementors should update their implementation to handle those new attributes/elements.

I'm not sure if it is feasible, but would it be an option that the 'call-back-API'/formatter-feedback-loop will be implemented using an XSL over the area tree? By sending layout feedback 'events' to the XSL stylesheet that handles the particular 'extension'. This would allow decoupling the use of the extension and implementation of the extension, and make them even implementation independent. (An implementation can of course optimise the extension by recognising it and implementing it natively).

Kind regards,

Nick Van den Bleeken

On 11 Feb 2013, at 20:10, Marko Hedler <mhedler@gmx.de>
 wrote:

> Am 11.02.2013 17:02, schrieb Dave Pawson:
>> On 11 February 2013 13:38, Marko Hedler <mhedler@gmx.de> wrote:
>>> Dynamic processing is well known by "old style" publishing systems like
>>> xyvision, app(3b2) etc.
>>> e.g. app(3b2) provides a bunch of variables accessible during the rendering
>>> process.
>>>
>>> The problem with FO is,
>> We know the problems, do you have suggestions for improvement to the rec?
> As far as I can overlook the problem, a lot of important information is already contained in the area tree.
> I am not sure if the rec says anything about at witch particular time a rederer must output an area tree (or must output an area tree at all). I was thinking of a page by page area tree.
>
> regards
> Marko
>
>
>
>>
>>
>>
>> regards
>>
>
>
>
>


________________________________

Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer

Received on Tuesday, 12 February 2013 08:08:24 UTC