xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: space-start and space-end for block-areas
Date Mon, 31 Jul 2006 17:32:48 GMT
Really want to dig that one out again? :-) 

Before I go into details inline below, let me stress that the margin-*
properties are defined in XSL-FO for compatibility with CSS. They don't
play a direct role in the FO geometry. 5.3.2 simply tells us how to map
the margin-* properties to start/end-indent. Furthermore, I think you
are mixing property evaluation (refinement stage) with the area model 
(layout stage). 4.4.1 is about the area model and includes stuff like
instrusion-adjustment which is absolutely no topic at property handling
level (chapter 4 vs. chapter 5). So you can't just mix equations from
chapter 4 and 5.

On 31.07.2006 17:33:28 Vincent Hennebert wrote:
> Hi all,
> I think there is a problem in the spec regarding the space-start and
> space-end traits for block-areas. The like-named properties only apply
> to inline-level formatting objects, so I guess that for block-areas
> those traits are indirectly-derived from other properties (start-indent
> and margin-*). The problem is that this is explained nowhere in the spec
> how to compute those traits, although I guess they should be given the
> values of the corresponding margin properties.
> Let me remind the three points of the spec which IMO are involved here:
> 1. in section 4.4.1, "Stacked Block-areas", there is a rule, among
>    others, stating that for a block-area:
> 	"the start-edge of its allocation-rectangle is parallel to the
> 	start-edge of the content-rectangle of R (where R is the closest
> 	ancestor reference-area of B), and offset from it inward by a
> 	distance equal to the block-area's start-indent plus its
> 	start-intrusion-adjustment (as defined below), minus its
> 	border-start, padding-start, and space-start value"
> 2. in section 5.3.2, "Margin, Space and Indent Properties", there are
>    rules for computing the values of start- and end-indent when margin-*
>    is specified, and vice-versa.
> 3. in section 5.1.2, "Computed Values", there is the following:
> 	"Specifying a value for one property determines both a computed
> 	value for the specified property and a computed value for the
> 	corresponding property."
>    So in our situation, if margin-* is not specified then it must be
>    computed from the (possibly inherited) specified value of
>    start-indent.
>    Here I disagree (but I may be wrong) with the IndentInheritance Wiki
>    page, where it is written (e.g., in the first example) that the rules
>    from 5.3.2 are not always triggered. In my opinion they are,
>    otherwise we can't compute the value of the space-start trait (more
>    below).
> Now, let's consider the following problem:
> - writing-mode is lr-tb, reference-orientation is 0 (most common case in
>   western countries);
> - we have an fo:block;
> - we want to compute the offset of the start-edge of the generated
>   block-areas's content-rectangle from the start-edge of the closest
>   ancestor reference-area's content-rectangle.
> Let's assume that:
> - xa is the x-coordinate of the start edge of the block-area's
>   allocation rectangle;
> - xc is the x-coordinate of the start edge of its content rectangle;
> - the origin of the coordinate system is the start-edge of the
>   content-rectangle of the closest ancestor reference-area;
> - there is no side-float so we can forget the start-intrusion-adjustment
>   in the formulae.
> Then we have the following:
>     (1) xa = xc - start-indent (definition of allocation-rectangle in 4.2.3)

with no intrusion adjustment, also: xc = 0 + start-indent (7.10.7)

(inserting xc in (1)) --> xa = 0

7.10.7 makes a statement for the area model.

>     (2) xa = start-indent - border-start - padding-start - space-start
> (section 4.4.1)

With no intrusion adjustment:
(J1) space-start = start-indent - border-start - padding-start
(variables are traits here)

And that's not the same as 5.3.2:
margin-left = start-indent - inherited(start-indent) - padding-left
   - border-left-width
(variables are properties here)

More on that below.

> That gives us the offset of the block-area's content rectangle:
>     (3) xc = 2*start-indent - border-start - padding-start - space-start
> If margin-left is set on the fo:block (and assuming that the inherited
> value of start-indent is 0), start-indent is computed like that:
>     start-indent = margin-left + padding-left + border-left-width
> which gives us for xc:
>     xc = 2*margin-left + padding-left + border-left-width - space-start
> This corresponds to the intuitive understanding provided that
> space-start is set to margin-left.
> If margin-left isn't specified but start-indent is, then the definition
> of the start-indent property (§7.10.7) lets us expect that
>     xc = start-indent
> So the formula (3) becomes:
>     start-indent = 2*start-indent - border-start - padding-start - space-start
> which works only if
>     space-start = start-indent - border-start - padding-start
> Again, this is ok if we give to space-start the value of margin-left
> computed according to section 5.3.2.
> Thus I think me may assume that the space-start and space-end traits for
> block-areas are given the computed values of the corresponding margin
> properties.
> Now there is a problem if the inherited value of start-indent is not 0.
> Then the value of space-start becomes (3rd formula of section 5.3.2):
>     space-start = start-indent - inherited-start-indent - padding-left
> - border-left-width

No, 5.3.2 says:

margin-left = start-indent - inherited(start-indent) - padding-left
   - border-left-width

margin-left != space-start !!!

space-start depends on the intrusion-adjustment. margin-left does not.
Furthermore, in a different writing more "start" does not correspond to

I think here's where you start mixing things. 5.3.2 is entirely about
calculating between converting between start/end-indent and its
corresponding properties. space-start is nowhere in 5.3.2.

> so
>     xc = start-indent + inherited-start-indent
> which breaks the expected interpretation of the start-indent property in
> §7.10.7
> Applied to the following example, taken from the IndentInheritance Wiki
> page:
>     <fo:flow>
>       <fo:block start-indent="10pt">indented text
> 	<fo:block>nested block</fo:block>
>       </fo:block>
>     </fo:flow>
> For the nested block, start-indent is set to the inherited value of
> 10pt. margin-left is computed according to the formula of section 5.3.2:
>     margin-left = start-indent - inherited(start-indent) - 0 - 0
> 		= 10pt - 10pt - 0 - 0
> 		= 0

which is correct (refinement stage!).

> So space-start = 0,

Nope. space-start is 10pt 

(J1) space-start = start-indent - border-start - padding-start

start-indent (the trait) is directly derived from start-indent (the
property) here.

>     (2) xa = start-indent - border-start - padding-start - space-start

> and xc = 2*start-indent - 0 - 0 -0 = 20pt, which is
> not the expected value.
> I think the inherited value of start-indent should be removed from the
> third formula of section 5.3.2. Note that this would not break the
> inheritance of the start- and end-indent properties, which is another
> issue.

No, that's there to emulate the CSS box model. margins are additive,
start-indent is kind of absolute. That's why the inherited values are
necessary in the equations.

> So, I've the feeling that on this issue the spec is both incomplete (how
> to compute space-start) and inconsistent (intended effect of
> start-indent vs computation formulae).
> I'd like to have your opinions on this. If everyone agree this would
> probably be an opportunity for a message to the xsl-editors list. Or
> have I missed something?

I hope I was able to show what has gone wrong. I strongly believe that
there's nothing wrong with the spec. BTW, we've already verified these
interpretations with the xsl-editors.

Jeremias Maerki

View raw message