W3C home > Mailing lists > Public > www-xsl-fo@w3.org > March 2002

RE: Pushing the Limits

From: Arved Sandstrom <asandstrom@accesswave.ca>
Date: Sat, 23 Mar 2002 19:57:16 -0500 (EST)
To: "'Www-Xsl-Fo" <www-xsl-fo@w3.org>
Message-ID: <NIECINNOJOOPPAIFLMIGGEGJCEAA.asandstrom@accesswave.ca>
Hi, Paul

One clarification - in my examples or later discussion I have not advocated
what you imply that I have advocated, which is implementations deciding what
page-master to use based on keeps or content. In fact my proposed expected
result clearly says that there should be two (2) pages that use "small",
followed by pages that use "large".

What I was getting at had to do with assignment of content. Here I think
there is a disconnect between what you, as a spec _author_, know to be the
intentions of the spec, and what I, as a  spec implementor, actually read in

Number 1, the spec does _not_ ascribe any special semantics to the "always"
value on keeps. Certainly not in Section 4.8, nor in Sections 7.19.3-5.
"always" is meant to be a value which defines a keep stronger than any
number value. In B&W, that's all it says. Couple that with the assertion in
Section 4.8, that

"The area tree is constrained to satisfy all break conditions imposed. Each
keep condition must also be satisfied, except when this would cause a break
condition or a stronger keep condition to fail to be satisfied."

and I cannot conclude from this that "always" is treated one special way and
all numeric values are treated another way. I don't doubt that this is what
you _intended_.

I suggest that the spec, as it is now written, _requires_ that the keep
condition I have described in my example be satisfied. It _can_ be satisfied
in the manner I have described. I find no constraints (especially not in
Section 6.4.5) that rule this out. There are no rules that prohibit blank
pages. Stacking constraints certainly don't - not across page boundaries.

Obviously the letter of the law (this is how I initially read the spec; when
I run across errors or ambiguities then I start asking questions to discover
the spirit of the law) in this case can lead to ugliness. This is what David
and I later discussed.

So I am _not_ saying at all that I _like_ this solution. I am just saying
that the text of the Recommendation leads to these conclusions. In fact I
very much prefer what you say is the intended result, and I'd like to see
clarifications, corrections, and additions put in the spec to make this
happen. In the meantime I will implement based on what you say is the way
things should be, and I'll annotate my spec copy, and comment the relevant
code to boot.


-----Original Message-----
From: Paul Grosso [mailto:pgrosso@arbortext.com]
Sent: March 23, 2002 6:28 PM
To: Arved Sandstrom; 'Www-Xsl-Fo
Subject: Re: Pushing the Limits

At 23:24 2002 03 22 -0500, Arved Sandstrom wrote:
>I've got a question related to keeps.

>Let's say that I have 2
>simple-page-masters defined: one called "small", with a fairly small
>region-body, and one called "large", with a larger region-body.
>The flow content looks like
><fo:block break-after="page">NOT MUCH STUFF</fo:block>
><fo:block keep-together.within-page="1">
>    .... QUITE A LOT OF STUFF ....

What you probably want to have here for the sake of your
point is keep-together.within-page="always".  With any
lesser value, the implementation is allowed to say "well,
the stylesheet says it would be nice to keep it together,
but since there is too much to fit on the page, I guess
I'll break it anyway."

Back to your question, implementations are not expected to decide
what page master to use based on keeps and/or the page size.  The
only conditions that are used to pick page masters are those "constraints
of the corresponding sub-sequence specifier" and "There are three
traits, page-position, odd-or-even, and blank-or-not-blank that
specify the sub-conditions on the use of the referenced page-master."

Therefore, an implementation would pick the page master based
on those three traits, find out that its height is "small",
discover that it's got a chunk kept together with a keep
condition of strength 1 and that that chunk's height is greater
than the height of the page, so it realizes it must ignore that
keep condition.  (The point of keep strengths is that, once keep
conditions of strength 1 are ignored, then if there are sub-chunks
of the whole chunk kept together with strength 2, the implementation
would obey those and break between subchunks--unless a single
subchunk were larger than a page, then it would have to ignore
the keep condition on that subchunk and look for a break within
that subchunk while attempting to obey all keep conditions
therein of strength 3 or greater, etc.)

If (and only if) the keep condition's strength were "always", then
there would be an overflow condition on the page, and that would
be handled by the implementation depending on the value of
the overflow property (and note that only values of "auto"
[user agent dependent] and "visible" are required to be supported).
In no case would an overflow situation cause an implementation to
choose another page master.


>The fo:flow, for sake of simplicity, contains these only.
>(SPM) "small" cannot accommodate the second block, but SPM "large" can.
>Furthermore, the containing page-sequence maps to
><fo:page-sequence-master master-name="psm">
>    <fo:single-page-master-reference master-reference="small"/>
>    <fo:single-page-master-reference master-reference="small"/>
>    <fo:repeatable-page-master-reference master-reference="large"/>
Received on Sunday, 24 March 2002 07:50:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:54 UTC