Re: New Year. Renewed activity? New Chair?

I have a personal opinion regarding your questions, Patrick.

At 2013-02-07 21:09 +0100, Patrick Gundlach wrote:
>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.

>Many applications require dynamic layout optimization.

Granted.  But can those optimizations be declared as rendering 
requirements rather than a formatting requirement?

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.

>The problem I see with XSL-FO is mostly that the layout is more or 
>less fixed before rendering.

Absolutely, yes, because the transformation that specifies the layout 
is entirely complete before the formatter has the opportunity to 
render the layout.  From the kind of transformations I do, I cannot 
accommodate a feedback loop from the formatter.

>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.

>If you have a chunk of text and you need to be sure that it has at 
>most some given dimensions, you can only find out about the size of 
>the text if you really typeset it. --

Or, you say declaratively, "this chunk of text is to be rendered 
within the following dimensions" (which isn't (yet) in XSL-FO).  Why 
does the creator of the XSL-FO have to be worried about the possible 
ways this is done?  If there are multiple ways this could be done, 
then parameterize the ways as properties of the intention to keep the 
text within the dimensions.  Then the renderer knows all of the 
characteristics of the author's intent with the block of text.  One 
of those properties would give the formatter constraints to play with 
the font size.

The renderer typically knows better than me what to do with the dots 
on the page.  If the act of adjusting the rendering to accommodate 
the layout is very repetitive, then I don't want to do it.  I want to 
give the renderer the permission to do different things (or its own 
things) to get the result I want.

>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.  Perhaps there is enough interest in the community to change 
the processing model for XSL-FO, but that isn't of interest to me.  I 
like that I simply declare what I want done and then let the 
formatter do it for me.  For the kind of publishing I've been doing, 
I don't need the feedback loop that isn't there.

>I would like to hear any opinions on that matter.

Perhaps your ideas could be incorporated in a new processing model, 
distinct from XSL-FO.

>I'll be off to xmlprague friday-monday,

Lucky!  I'm sad to be missing the conference.  It is a favourite of mine.

Enjoy the conference, and good luck in your development!  I hope you 
find this feedback useful.

. . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/f/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal

Received on Thursday, 7 February 2013 20:49:18 UTC