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

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

From: G. Ken Holman <gkholman@CraneSoftwrights.com>
Date: Thu, 07 Feb 2013 16:40:16 -0500
Message-Id: <>
To: "public-ppl@w3.org" <public-ppl@w3.org>
At 2013-02-07 22:23 +0100, Patrick Gundlach wrote:
>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.

Ah ... forgive me!  I misunderstood.

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

I would hope so!  But I'm not the moderator.

But if you have useful, real-world requirements for formatting ... 
perhaps they can be shoehorned into XSL-FO without any 
discomfort.  That was my interest in analyzing your 
requirements.  Building on something existing may help you get 
farther than starting something new.

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

Granted.  But perhaps the application then declaratively provides a 
choice of layouts and lets the formatter choose between them.  I 
accept that the decisions are application-specific, but the 
application is only so smart to know what possibly could be done ... 
perhaps it is enough that the application considers all the 
possibilities and provides them as part of its intent:  "I want the 
following possible layouts to be considered, in the given order, 
until the first one fits."  Let the formatter arbitrate, given your 
intent of precedence reflecting your preference.

If your application has to be prepared anyway to handle exceptions, 
perhaps simply handle them ahead of time and express your intent that 
one of the layouts be chosen to fit.

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

That particular facility has a valuable concept of "keep strength" 
that governs what happens when keeps must "break" because they do not 
fit.  Nested "keeps" can be declared, with higher strength, not 
themselves to be broken.

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

Ah ... but then move the complexity to the application creating the 
stream and make the stream itself simple and restricted to concepts 
of layout, not concepts of the problem space.  Divorce the two 
concepts.  The problem space might dictate that three possible 
layouts could express the meaning of the content ... the formatter 
space simply arbitrates between them given the creator's intent for 

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

And there may be a user base out there willing to embrace that 
approach.  And there may be other vendors out there willing to 
satisfy the marketplace in such a way as to warrant participating in 
its standardization.

But there is a lot in XSL-FO to build on if your concepts can enhance 
what is already there.

Please don't let my feedback hold you back!  You asked for comments 
and I simply framed mine in the context of building on top of XSL-FO.

. . . . . . . . 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 21:41:19 UTC

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