xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Hennebert" <vincent.henneb...@enseeiht.fr>
Subject space-start and space-end for block-areas
Date Mon, 31 Jul 2006 15:33:28 GMT
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)
    (2) xa = start-indent - border-start - padding-start - space-start
(section 4.4.1)
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
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
So space-start = 0, 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.

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?

Thanks,
Vincent
Mime
View raw message