Other paged media processing approach (was: New Year. Renewed activity? New Chair?)

Hello Ken,

first of all, thank you very much for your valuable comments.

An "answer" from me before I'd like to get into details: my thought was never to extend XSL-FO, but to show a different approach. I guess I have not done enough to make this clear. And I am a bit uncertain if I am in the correct group - I hope I am allowed to discuss my thoughts here.



>> The kind of documents I deal with is product catalogs and other applications that need much optimization during the layout process.
>> 
>> * Can we fit another product onto the page by rearranging the products that are already on the page?
>> * If we reduce the font size, we will be able to fit the text on one page.
>> * The tables and images should be positioned so that the text in all given languages easily fit in the place above the table/image.
> 
> If you can express those concepts declaratively, thus not requiring interaction with the transformation, then they could likely be considered whether or not they fit in a future version of XSL-FO.

I think items 2+3 can be expressed declaratively, I didn't think of it. Item 1 would be very hard IMO, because it is very application specific. 

>> Many applications require dynamic layout optimization.
> 
> Granted.  But can those optimizations be declared as rendering requirements rather than a formatting requirement?

Not sure about this. The constraints for "rearranging the page" are probably very different in every application. Some applications (=documents) may allow the font size to be reduced, other applications could make using different product images as the first step to reduce /increase space as a requirement and so on. 

> Consider the very useful keep-together="{strength}" facility in XSL-FO:  the layout states that the content needs to be kept together.  The rendering determines if that layout is going on one page or the next.

I have not (except for table rows which can be forced to stay together) implemented such a facility. Good idea that I will keep in mind.

>> It is hard to get information back from the renderer to the place where you decide on the actual layout of the page. Why is this a problem?
> 
> Because however the XSL-FO is created, it is thrown over the wall for rendering without a feedback loop.  So, without a feedback loop, the creator of the XSL-FO has to express their intent of what they want done ... they don't do it themselves.  The formatter interprets their intent.

That might be the ultimate goal - to express the intent and make the system do the hard work. I'd be curious about the size of the problem space though, might be very big?

[...]

>> Now my approach is to interpret the layout instructions _inside_ the renderer so you can always ask the renderer to typeset something on a virtual page and find out about the exact dimension.
> 
> Interesting ... but I feel it breaks the existing model of XSL-FO.

yes, surely. My approach is very different from the XSL-FO approach and not compatible in any way. I think XSL-FO has its place. I suggest another approach for dynamic XML to PDF rendering.


Thanks again

Patrick


speedata UG (haftungsbeschränkt)
-------------------------------------
Telefon  030/57705055   
Mobil    0178/1967142
Mail     gundlach@speedata.de
Web      www.speedata.de

Eisenacher Straße 101
10781 Berlin
-------------------------------------
Amtsgericht Charlottenburg HRB 135360 B
Geschäftsführer: Patrick Gundlach
USt-IdNr: DE278023065

Received on Thursday, 7 February 2013 21:24:12 UTC