4.3.2 Overconstrained space-specifiers

[Jeremias Maerki <de...@jeremias-maerki.ch>]

You will have seen that I've been working on overconstrained documents.
5.3.4 Overconstrained Geometry is more or less implemented, so now I
need to have a look at 4.3.2 which proves quite difficult to understand.
At least I can't make much sense of it ATM. Here's what I found out so
far with a some help from Manuel via IM:

First of all, what's strange is that the situation in which
overconstrainment relaxing is applied is defined more or less by a
single example, and a wrong one at that:

"for example an incompletely-filled fo:block with a specified size."

The problem: fo:block can't have a specified size and therefore can't by
incompletely filled. The block-progression-dimension property doesn't
apply to fo:block. I assume fo:block-container was meant.

Take this example by Manuel:

<fo:block-container block-progression-dimension="100pt">
  <fo:block space-after="50pt" space-after.conditionality="retain">
    <fo:instream-foreign-object height="90pt" ...
  </fo:block>
</fo:block-container>

The contents make up 140pt together while the block-container is only
100pt high. A classic overflow scenario, but probably an overconstrained
area tree as described by 4.3.2. Assuming display-align="before", the
last normal child of P (= the last normal area of the block-container in
this case) has a space-after which is subject to overconstrainment
relaxing.

Ok, so we run this through rule 4 in space-resolution. That means we set
the maximum value of the space-specifier of the fo:block to the
block-progression-dimension of the containing block-area which is the
reference are of the block-container (= 100pt). Right? If yes, that
makes the space-after even bigger than before not helping the situation
at all.

Or what do you do here?

<fo:block-container block-progression-dimension="100pt">
  <fo:block space-after="50pt" space-after.conditionality="retain">
    <fo:instream-foreign-object height="90pt" ...
  </fo:block>
  <fo:block>test</fo:block>
</fo:block-container>

You don't even have a space-after on the last normal child anymore.

Bottom line: I don't get it.

If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about
I'd love to read your thoughts. Otherwise, I will run this through the
XSL editors list.

Thanks,
Jeremias Maerki

Re: 4.3.2 Overconstrained space-specifiers

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Thanks, Luca. It does make sense but I'm having trouble mapping your
interpretation to what is written in the spec. I wonder: Do you agree
with me that my second example wouldn't be affected by the rules
described in 4.3.2? 

Anyway, I think I'm going to let this rest and instead concentrate on
detecting overflow situations. After all, this stuff here seems pretty
exotic.



On 09.12.2005 14:40:01 Luca Furini wrote:
> Jeremias Maerki wrote:
> 
> > You will have seen that I've been working on overconstrained documents.
> > 5.3.4 Overconstrained Geometry is more or less implemented, so now I
> > need to have a look at 4.3.2 which proves quite difficult to understand.
> > At least I can't make much sense of it ATM.
> > 
> > [...]
> > 
> > If anyone has an idea what rule 4 in 4.3.1 or the section 4.3.2 is about
> > I'd love to read your thoughts. Otherwise, I will run this through the
> > XSL editors list.
> 
> I always thought (probably wrongly) these sections of the spec refer to 
> the page regions, maybe because of the property display-align, and more as 
> a way to "formally justify" what is usually done than as prescribing some 
> particular behaviour.
> 
> To be more clear (I hope :-)): region viewports usually have a well-known 
> height (unless there is only a single page whose height is unbounded); 
> their area children don't always fill them completely.  The content areas 
> are placed at the top / center / bottom of the viewport according to the 
> value of display-align: but, as these extra spaces may be in contrast with 
> the space properties of the first and last child areas, we need, from a 
> formal point of view, a rule saying that we are allowed to do this, 
> otherwise the specs would be inconsistent.
> 
> In other words, I always read these rules as: "spaces added ad the top / 
> bottom of a page to implement display-align have greater precedence than 
> space-before or space-after traits of the child areas". According to me, 
> rule 4 should state something like this: "the maximum value of the 
> space-specifier is set to the difference between the containing height and 
> the content height".
> 
> Don't know if this makes any sense ...
> 
> Regards
>      Luca



Jeremias Maerki