xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject 4.3.2 Overconstrained space-specifiers
Date Mon, 05 Dec 2005 10:53:27 GMT
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" ...

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

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

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.

Jeremias Maerki

View raw message