W3C home > Mailing lists > Public > public-ppl@w3.org > February 2013

Re: Other paged media processing approach - summary

From: Marko Hedler <hedler@hdm-stuttgart.de>
Date: Tue, 12 Feb 2013 09:22:38 +0100
Message-ID: <5119FBCE.70800@hdm-stuttgart.de>
To: public-ppl@w3.org

Am 12.02.2013 09:07, schrieb Nick Van den Bleeken:
> 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).
The problem with this "call-back-API" through area tree is, that (as far 
as I know), all known formatters write out the area tree after rendering 
the whole document. If we could access the area tree right after a 
single page was rendered, to build a loop page by page, would lead to an 
enormous impact.
Does the spec says anything about at which particular time an area tree 
has to be written out?


> 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


Hochschule der Medien
Prof. Dr.-Ing. Marko Hedler
Publishing - Cross-Media-Systeme
Nobelstrasse 10
70569 Stuttgart

Tel: 0711/8923-2141
Fax: 0711/8923-2180
Received on Tuesday, 12 February 2013 08:23:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:57:25 UTC