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: Tony Graham <tgraham@mentea.net>
Date: Fri, 8 Feb 2013 10:35:11 -0000 (GMT)
Message-ID: <53392.91.219.46.24.1360319711.squirrel@mail3.webfaction.com>
To: "public-ppl@w3.org" <public-ppl@w3.org>
I really should get on a plane and fly to another country more often if
there's going to be mailing list activity every time I do it.

Patrick, I'm at XML Prague, too, so hopefully we can meet up.

On Thu, February 7, 2013 9:40 pm, G. Ken Holman wrote:
> 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.

Feedback from the processing stage is/was in the XSL 2.0 requirements [1],
and copyfitting is in the last XSL 2.0 WD [2].

In my current day-job, I sit next to people who spend their days
formatting pages from XML, and they spend a lot of time trying to make an
updated version of part of a document fit the same number of pages as the
previous version, or make it fit a given number of pages.  They're not
using XSL-FO, and they couldn't use XSL-FO because there are AFAIK no
XSL-FO tools that let you tweak the made-up pages.

Just this morning -- before I saw any of these emails -- I was reflecting
both that the up-and-coming CSS layout engine don't seem set to let you do
that either and that it's always been the plan for xmlroff to let
applications work with the area tree, even if xmlroff has yet to get
beyond making the area tree visible as read-only structures.

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

When this list needs a moderator, I expect it will get one, but the CG
title carefully doesn't even mention XML, so straying from XSL-FO doesn't
mean it's straying off-topic.

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

As above, feedback and copyfitting are in the requirements and partly in
the last WD.  The phrase that was bandied about when discussing
requirements, but that wasn't proper standards-speak, was "more
magazine-like" layout (or similar).

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

IMO, the formatter-as-black-box approach of XSL-FO is partly historical
since it was the DSSSL, etc., model and partly pragmatism because it meant
existing formatters could be reworked with XSL-FO frontends.

The fact that you can't query the XSL-FO formatter version in any standard
way using XSLT system properties has always seemed odd to me, too.  This
has lead to stylesheets such as DocBook require you to explicitly set a
parameter to tell the stylesheet which processor to expect, and lead to
many mailing list posts of the form "Did you set the FOP parameter to
'1'?".

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

And people are only going to be only so smart in setting up spaces and
keeps and breaks in advance for all possible permutations of the markup
that becomes XSL-FO.  Lights-out formatting isn't always going to be the
best solution for everybody.

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

The vendors who market XSL-FO apparently aren't willing to participate in
standardisation of its next version, so it seems Patrick is on an equal
footing with the rest of us.

Regards,


Tony.


Tony Graham                                   tgraham@mentea.net
Consultant                                 http://www.mentea.net
Mentea       13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
 --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
    XML, XSL-FO and XSLT consulting, training and programming

[1] http://www.w3.org/TR/2008/WD-xslfo20-req-20080326/#N66678
[2] http://www.w3.org/TR/xslfo20/#copyfitting
Received on Friday, 8 February 2013 10:35:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 8 February 2013 10:35:39 GMT