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

Re: Customer requirement, a critque

From: Tony Graham <tgraham@mentea.net>
Date: Mon, 25 Feb 2013 15:35:17 -0000 (GMT)
Message-ID: <32044.>
To: "Print and Page Layout Community Group" <public-ppl@w3.org>
On Mon, February 25, 2013 2:35 pm, Jirka Kosek wrote:
> On 25.2.2013 7:32, Patrick Gundlach wrote:
>>   A -> B -> A -> B -> A -> B -> A -> B -> C
>> And then I have a hard time to see how this can be compared to existing
>> XSL-FO 1.1 workflows.
> Well actually this is quite common workflow if you have enough
> challenging requirements. Most FO processors can generate final layout
> in form of XML instead of PDF. You can take this as an input to second
> pass where you can change generated FOs based on result of a previous
> formatting round.

The XSLT 2.0 requirements also envisions an (expanded) expression language
[1] for evaluation by the FO processor, post-XSLT, for doing things based
on sizes of objects or calculating subtotals.

Doing things by moving some of the decision making into the formatter may
be easier for people to come to terms with compared to having to make
sense of an area tree and relate that back to FOs and, eventually, back to
the original XML.

In all of this, I don't know if we're drawing the same boxes in our heads
when it comes to working out where the FO processor starts, whether it
includes either the XSLT stage or the actual renderer, or where the
envisaged feedback would go.

> Of course this is not based on any standard, each FO implementation uses
> it's own format to store final layout.

One of the things that I've been wondering about is whether it's
worthwhile coming up with a schema for the area tree and writing filters
from the various formatters' area tree output format so any multi-pass
processing isn't quite so dependent on a particular formatter.

If there was a common XSLT function library for accessing parts of the
area tree, that would be even better.

> Also one can imagine extension instruction for XSLT which will invoke FO
> rendering of a partial FO document. Based on result of formatting XSLT
> code can then decide to throw away this result or put it into final FO
> file. This way many requirements including copy-fitting can be quite
> easily implemented. I think this is a way to go. It builds on existing
> XSLT+FO solution, but adds optional ability to invoke formatting in a
> middle of transformation -- something which was up-to-date possible only
> in lower level formatting engines like TeX.

See requirement #10 [2] that I added earlier today, which discusses three
trial layouts of every table in a document to work out whether each table
is best as column-width, page-width, rotated with a single column, or
rotated within a page.  Today, I'd look at doing the conditional
formatting before running the main stylesheet and presenting
easily-digestible results to the stylesheet that has to make the decision
about how to format the tables in the final result.



[1] http://www.w3.org/TR/xslfo20-req/#N66708
[2] http://www.w3.org/community/ppl/wiki/CustomerRequirements
Received on Monday, 25 February 2013 15:35:44 UTC

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