You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Vincent Hennebert <vi...@enseeiht.fr> on 2006/07/31 17:33:28 UTC
space-start and space-end for block-areas
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
Re: space-start and space-end for block-areas
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Nah, already fixed it. Looks like I did not port a change I did for the
variant that breaks property inheritance to the compliant variant. As
soon as you use margin-left instead of start-indent the results came out
wrong because the code tried to unnecessarily back-calculate the margin
and from that the start-indent again although that value is exlicitely
set in the case where it went wrong.
http://svn.apache.org/viewvc?rev=427938&view=rev
http://svn.apache.org/viewvc?rev=427939&view=rev
On 02.08.2006 09:31:39 Vincent Hennebert wrote:
> <snip/>
> > > > > PS: There seems to be a problem, then, with the third paragraph
> > > > > of the
> > > > > attached fo file. IIUC it should be placed 1 cm right from the black
> > > > > border. And if I remove the start-indent="0" attribute from the fo:block
> > > > > it should be placed 2 cm right. WDYT?
> > > >
> > > > Yes, that's what's happening and what should be happening. I don't see
> > > > the problem, sorry.
> > >
> > > Well, with my working copy I get the following results:
> > > When start-indent is explicitly set to "0cm" for the third paragraph,
> > > the text is placed 1 cm /left/ from the black border:
> > > http://atvaark.dyndns.org/~vincent/ref-area_start-indent-0cm.pdf
> > >
> > > When start-indent is unset, the text is placed 2 cm left from the black
> > > border:
> > > http://atvaark.dyndns.org/~vincent/ref-area_start-indent-none.pdf
> > >
> > > Same result with Fop 0.92beta. My working copy is up-to-date with the
> > > repository and contains no local modification. I wonder where is the
> > > problem. May I ask which results do others get?
> >
> > Damn, I had the "break indent inheritance" switch enabled. Seems to be a
> > bug then, somewhere in IndentPropertyMaker.computeConforming(). Grr.
>
> Should I open a Bugzilla entry for that? Or submit a disabled testcase?
> Or even both?
>
> Vincent
Jeremias Maerki
Re: space-start and space-end for block-areas
Posted by Vincent Hennebert <vh...@gmail.com>.
<snip/>
> > > > PS: There seems to be a problem, then, with the third paragraph
> > > > of the
> > > > attached fo file. IIUC it should be placed 1 cm right from the black
> > > > border. And if I remove the start-indent="0" attribute from the fo:block
> > > > it should be placed 2 cm right. WDYT?
> > >
> > > Yes, that's what's happening and what should be happening. I don't see
> > > the problem, sorry.
> >
> > Well, with my working copy I get the following results:
> > When start-indent is explicitly set to "0cm" for the third paragraph,
> > the text is placed 1 cm /left/ from the black border:
> > http://atvaark.dyndns.org/~vincent/ref-area_start-indent-0cm.pdf
> >
> > When start-indent is unset, the text is placed 2 cm left from the black
> > border:
> > http://atvaark.dyndns.org/~vincent/ref-area_start-indent-none.pdf
> >
> > Same result with Fop 0.92beta. My working copy is up-to-date with the
> > repository and contains no local modification. I wonder where is the
> > problem. May I ask which results do others get?
>
> Damn, I had the "break indent inheritance" switch enabled. Seems to be a
> bug then, somewhere in IndentPropertyMaker.computeConforming(). Grr.
Should I open a Bugzilla entry for that? Or submit a disabled testcase?
Or even both?
Vincent
Re: space-start and space-end for block-areas
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 1, 2006, at 20:29, Andreas L Delmelle wrote:
> On Aug 1, 2006, at 20:06, Andreas L Delmelle wrote:
>
> Again answering my own question/remark here:
Oops, sorry for the noise. Totally overlooked the outer block-
container... :(
Re: space-start and space-end for block-areas
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 1, 2006, at 20:06, Andreas L Delmelle wrote:
Again answering my own question/remark here:
<snip />
> One way around this would be to exclude the inherited value of
> start-indent if start-indent is specified on the FO.
> That would make it:
> *either* inherited *or* explicit, and not explicit *minus*
> inherited...?
>
> Correct interpretation?
Seems like the behaviour in the first case --explicit start-indent
equal to zero on the last block-- is correct, after all.
start-indent "specifies the distance from the start-edge of the
content-rectangle of the containing reference-area to the start-edge
of the content-rectangle of that block-area"
The containing reference-area being the region-viewport-area (?),
this would lead to the outer block being placed 2cm from the region-
body's start-edge, and the block-container only 1cm...
As for the other case:
The block-container generates its own reference-area, so a possible
inherited value of start-indent should be measured starting from the
b-c's start-edge (so if start-indent is not explicitly specified, the
start-edge of the content-rectangle of the last block should
virtually coincide with the start-edge of the content-rectangle of
the outer block --2cm from the region's start-edge).
Later
Andreas
Re: space-start and space-end for block-areas
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 1, 2006, at 19:53, Andreas L Delmelle wrote:
> <snip />
> Might be caused by something like:
> margin-left influences the start-indent property of the outer
> block, and this latter property is inherited... I'd debug in that
> direction: see what the call to PropertyList.getInherited() returns
> in IndentPropertyMaker line 107. I bet it's returning the 2cm.
>
> The specified start-indent on the block-container should actually
> reset this, so it seems to be a problem with computing the
> inherited value...
Just had another look. Suspicion confirmed, it seems.
see: PropertyList.getInherited()
if (isInherited(...)) { etc.
and start-indent is inherited, so this will always return the
computed value of the parent in that calculation.
One way around this would be to exclude the inherited value of start-
indent if start-indent is specified on the FO.
That would make it:
*either* inherited *or* explicit, and not explicit *minus* inherited...?
Correct interpretation?
Cheers,
Andreas
Re: space-start and space-end for block-areas
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 1, 2006, at 15:44, Jeremias Maerki wrote:
> On 01.08.2006 12:14:58 Vincent Hennebert wrote:
<snip />
>> Well, with my working copy I get the following results:
>> When start-indent is explicitly set to "0cm" for the third paragraph,
>> the text is placed 1 cm /left/ from the black border:
>> http://atvaark.dyndns.org/~vincent/ref-area_start-indent-0cm.pdf
Hmm... seems like the non-inherited margin-left property from the
outer fo:block influences the calculation.
1 - 2 = -1
>>
>> When start-indent is unset, the text is placed 2 cm left from the
>> black
>> border:
>> http://atvaark.dyndns.org/~vincent/ref-area_start-indent-none.pdf
0 - 2 = -2
> Damn, I had the "break indent inheritance" switch enabled. Seems to
> be a
> bug then, somewhere in IndentPropertyMaker.computeConforming(). Grr.
Might be caused by something like:
margin-left influences the start-indent property of the outer block,
and this latter property is inherited... I'd debug in that direction:
see what the call to PropertyList.getInherited() returns in
IndentPropertyMaker line 107. I bet it's returning the 2cm.
The specified start-indent on the block-container should actually
reset this, so it seems to be a problem with computing the inherited
value...
Cheers,
Andreas
Re: space-start and space-end for block-areas
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 01.08.2006 12:14:58 Vincent Hennebert wrote:
> <snip/>
> > > Ah yes, so this formula comes from the statement in 7.10.7 (BTW, in
> > > case
> > > of mixed writing modes / reference-orientations this statement is wrong;
> >
> > I don't think so. FOs like block-container create a viewport/reference
> > pair. The viewport-area does the rotation, the reference-area is already
> > in the same rotation as its immediate children.
>
> Well, again I may be wrong, but: in section 4.2.3 we have the following:
> "the content-rectangle of an area uses the inline-progression-direction
> and block-progression-direction of that area; but the border-rectangle,
> padding-rectangle, and allocation-rectangle use the directions of its
> parent area. Thus the edges designated for the content-rectangle may not
> correspond to the same-named edges on the padding-, border-, and
> allocation-rectangles."
>
> So if we want to put, say, some Japanese in an English text, the main
> flow would be in lr-tb writing-mode, and we would put an
> fo:block-container with a tb-rl writing-mode. The block-container would
> generate a viewport-reference pair of areas with the following mapping:
>
> border-rectangle, padding-rectangle, allocation-rectangle
> before-edge top
> after-edge bottom
> start-edge left
> end-edge right
> content-rectangle
> before-edge right
> after-edge left
> start-edge top
> end-edge bottom
>
> Note that in section 4.2.2, it is stated that "the start-edge and
> end-edge of the content-rectangle of [the reference-area] are parallel
> to the start-edge and end-edge of the content-rectangle of [the
> viewport-area]".
>
> If we set a start-indent for the fo:block-container, this would be the
> space between the left-edge (start-edge) of the flow's content-rectangle
> and the left-edge (after-edge) of the block-container's
> content-rectangle.
>
> WDYT?
Yes, that seems to be correct, but is only an effect. The start-indent
of the b-c affects only the viewport directly. The reference area is
then fit into the viewport's content rectangle which happens to be
rotated. Actually, I'd rewrite your last paragraph like this:
If we set a start-indent for the fo:block-container, this would be the
space between the left-edge (start-edge) of the flow's content-rectangle
and the left-edge (start-edge) of the block-container viewport's
content-rectangle.
>
> > > I thought they introduced the allocation-rectangle just for dealing with
> > > that).
> > > But then, the formula of 4.4.1 may be (greatly) simplified:
> > > xa = start-intrusion-adjustment
> > > If it is so complicated, is it because the formula (J1) may not always
> > > be true?
> >
> > I don't think it's that complicated. The spec just tries to explain the
> > relationships of the various properties and traits. I don't think all of
> > these statements are meant to be used as literal formulas. I think we
> > rarely, if at all, have to deal with the space-start trait, for example.
> > Right now, we shift in by start-indent and out again by padding-start
> > and border-start. That's all that's necessary to paint everything. Of
>
> Of course, but independantly of how this is actually implemented, I'd
> like to make sure I understand the formulae rightly.
>
>
> <snip/>
> > > Well, I think I get it now. It's frustrating to spend so much time
> > > in
> > > just trying to understand a spec...
> >
> > Imagine how I felt in the first half of 2005 while getting up to speed
> > with the mean details of the spec. It's just normal you feel that way.
> > If you look in the archives, you'll see that you're not alone. A feeble
> > consolation, I know.
>
> Yes, but still one. This seems to confirm that the problem relies in the
> spec, not in my brain ;-)
>
>
> > > Thank you, Jeremias.
> > > Vincent
> > >
> > >
> > > PS: There seems to be a problem, then, with the third paragraph of the
> > > attached fo file. IIUC it should be placed 1 cm right from the black
> > > border. And if I remove the start-indent="0" attribute from the fo:block
> > > it should be placed 2 cm right. WDYT?
> >
> > Yes, that's what's happening and what should be happening. I don't see
> > the problem, sorry.
>
> Well, with my working copy I get the following results:
> When start-indent is explicitly set to "0cm" for the third paragraph,
> the text is placed 1 cm /left/ from the black border:
> http://atvaark.dyndns.org/~vincent/ref-area_start-indent-0cm.pdf
>
> When start-indent is unset, the text is placed 2 cm left from the black
> border:
> http://atvaark.dyndns.org/~vincent/ref-area_start-indent-none.pdf
>
> Same result with Fop 0.92beta. My working copy is up-to-date with the
> repository and contains no local modification. I wonder where is the
> problem. May I ask which results do others get?
Damn, I had the "break indent inheritance" switch enabled. Seems to be a
bug then, somewhere in IndentPropertyMaker.computeConforming(). Grr.
Jeremias Maerki
Re: space-start and space-end for block-areas
Posted by Vincent Hennebert <vh...@gmail.com>.
<snip/>
> > Ah yes, so this formula comes from the statement in 7.10.7 (BTW, in
> > case
> > of mixed writing modes / reference-orientations this statement is wrong;
>
> I don't think so. FOs like block-container create a viewport/reference
> pair. The viewport-area does the rotation, the reference-area is already
> in the same rotation as its immediate children.
Well, again I may be wrong, but: in section 4.2.3 we have the following:
"the content-rectangle of an area uses the inline-progression-direction
and block-progression-direction of that area; but the border-rectangle,
padding-rectangle, and allocation-rectangle use the directions of its
parent area. Thus the edges designated for the content-rectangle may not
correspond to the same-named edges on the padding-, border-, and
allocation-rectangles."
So if we want to put, say, some Japanese in an English text, the main
flow would be in lr-tb writing-mode, and we would put an
fo:block-container with a tb-rl writing-mode. The block-container would
generate a viewport-reference pair of areas with the following mapping:
border-rectangle, padding-rectangle, allocation-rectangle
before-edge top
after-edge bottom
start-edge left
end-edge right
content-rectangle
before-edge right
after-edge left
start-edge top
end-edge bottom
Note that in section 4.2.2, it is stated that "the start-edge and
end-edge of the content-rectangle of [the reference-area] are parallel
to the start-edge and end-edge of the content-rectangle of [the
viewport-area]".
If we set a start-indent for the fo:block-container, this would be the
space between the left-edge (start-edge) of the flow's content-rectangle
and the left-edge (after-edge) of the block-container's
content-rectangle.
WDYT?
> > I thought they introduced the allocation-rectangle just for dealing with
> > that).
> > But then, the formula of 4.4.1 may be (greatly) simplified:
> > xa = start-intrusion-adjustment
> > If it is so complicated, is it because the formula (J1) may not always
> > be true?
>
> I don't think it's that complicated. The spec just tries to explain the
> relationships of the various properties and traits. I don't think all of
> these statements are meant to be used as literal formulas. I think we
> rarely, if at all, have to deal with the space-start trait, for example.
> Right now, we shift in by start-indent and out again by padding-start
> and border-start. That's all that's necessary to paint everything. Of
Of course, but independantly of how this is actually implemented, I'd
like to make sure I understand the formulae rightly.
<snip/>
> > Well, I think I get it now. It's frustrating to spend so much time
> > in
> > just trying to understand a spec...
>
> Imagine how I felt in the first half of 2005 while getting up to speed
> with the mean details of the spec. It's just normal you feel that way.
> If you look in the archives, you'll see that you're not alone. A feeble
> consolation, I know.
Yes, but still one. This seems to confirm that the problem relies in the
spec, not in my brain ;-)
> > Thank you, Jeremias.
> > Vincent
> >
> >
> > PS: There seems to be a problem, then, with the third paragraph of the
> > attached fo file. IIUC it should be placed 1 cm right from the black
> > border. And if I remove the start-indent="0" attribute from the fo:block
> > it should be placed 2 cm right. WDYT?
>
> Yes, that's what's happening and what should be happening. I don't see
> the problem, sorry.
Well, with my working copy I get the following results:
When start-indent is explicitly set to "0cm" for the third paragraph,
the text is placed 1 cm /left/ from the black border:
http://atvaark.dyndns.org/~vincent/ref-area_start-indent-0cm.pdf
When start-indent is unset, the text is placed 2 cm left from the black
border:
http://atvaark.dyndns.org/~vincent/ref-area_start-indent-none.pdf
Same result with Fop 0.92beta. My working copy is up-to-date with the
repository and contains no local modification. I wonder where is the
problem. May I ask which results do others get?
Thanks,
Vincent
Re: space-start and space-end for block-areas
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 01.08.2006 09:52:42 Vincent Hennebert wrote:
> > Really want to dig that one out again? :-)
>
> He he ;-) I guess yes.
>
> I was starting to look at all the intrusion-adjustment and -displace
> stuff when I stumbled upon this issue. I need to have an absolutely
> clear understanding of that if I want to implement side-floats
> correctly.
I suspected that was the case.
>
> > 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
>
> <rant> And that complicates things because we have to adapt the wordings
> of one spec to another one. And this is all the more difficult as there
> are always uncertainties in specs. They should be written in some kind
> of formal language IMHO. </rant>
I hear you. My past 19 months of intensive work on FOP had me wish for a
simpler, clutter-free XSL-FO.
> > 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.
>
> Well, I'm aware of the difference between properties and traits, but I
> was trying to find from which properties the space-start trait may be
> derived for block-areas. Because the space-start property only applies
> to inline-level formatting objects.
>
>
> <snip/>
> > > 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.
>
> Ok.
>
>
> > > (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)
>
> Ah yes, so this formula comes from the statement in 7.10.7 (BTW, in case
> of mixed writing modes / reference-orientations this statement is wrong;
I don't think so. FOs like block-container create a viewport/reference
pair. The viewport-area does the rotation, the reference-area is already
in the same rotation as its immediate children.
> I thought they introduced the allocation-rectangle just for dealing with
> that).
> But then, the formula of 4.4.1 may be (greatly) simplified:
> xa = start-intrusion-adjustment
> If it is so complicated, is it because the formula (J1) may not always
> be true?
I don't think it's that complicated. The spec just tries to explain the
relationships of the various properties and traits. I don't think all of
these statements are meant to be used as literal formulas. I think we
rarely, if at all, have to deal with the space-start trait, for example.
Right now, we shift in by start-indent and out again by padding-start
and border-start. That's all that's necessary to paint everything. Of
course, with side-floats this might get a little more complicated.
>
> > 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.
>
> I don't think so, as there is a start-intrusion-adjustment trait for
> that. But I'm ok with the rest.
Ok, maybe margin-left is often the same value as space-start, but it's
still important not to mix margin-left (property) and space-start (trait).
There's a complex relationship between them and not a simple one as you
implied. margin-left is a corresponding, absolute property and has no
direct play in the internal area model of XSL-FO.
> <snip/>
> > > 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.
>
>
> Well, I think I get it now. It's frustrating to spend so much time in
> just trying to understand a spec...
Imagine how I felt in the first half of 2005 while getting up to speed
with the mean details of the spec. It's just normal you feel that way.
If you look in the archives, you'll see that you're not alone. A feeble
consolation, I know.
> Thank you, Jeremias.
> Vincent
>
>
> PS: There seems to be a problem, then, with the third paragraph of the
> attached fo file. IIUC it should be placed 1 cm right from the black
> border. And if I remove the start-indent="0" attribute from the fo:block
> it should be placed 2 cm right. WDYT?
Yes, that's what's happening and what should be happening. I don't see
the problem, sorry.
Jeremias Maerki
Re: space-start and space-end for block-areas
Posted by Vincent Hennebert <vh...@gmail.com>.
> Really want to dig that one out again? :-)
He he ;-) I guess yes.
I was starting to look at all the intrusion-adjustment and -displace
stuff when I stumbled upon this issue. I need to have an absolutely
clear understanding of that if I want to implement side-floats
correctly.
> 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
<rant> And that complicates things because we have to adapt the wordings
of one spec to another one. And this is all the more difficult as there
are always uncertainties in specs. They should be written in some kind
of formal language IMHO. </rant>
> 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.
Well, I'm aware of the difference between properties and traits, but I
was trying to find from which properties the space-start trait may be
derived for block-areas. Because the space-start property only applies
to inline-level formatting objects.
<snip/>
> > 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.
Ok.
> > (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)
Ah yes, so this formula comes from the statement in 7.10.7 (BTW, in case
of mixed writing modes / reference-orientations this statement is wrong;
I thought they introduced the allocation-rectangle just for dealing with
that).
But then, the formula of 4.4.1 may be (greatly) simplified:
xa = start-intrusion-adjustment
If it is so complicated, is it because the formula (J1) may not always
be true?
> 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.
I don't think so, as there is a start-intrusion-adjustment trait for
that. But I'm ok with the rest.
<snip/>
> > 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.
Well, I think I get it now. It's frustrating to spend so much time in
just trying to understand a spec...
Thank you, Jeremias.
Vincent
PS: There seems to be a problem, then, with the third paragraph of the
attached fo file. IIUC it should be placed 1 cm right from the black
border. And if I remove the start-indent="0" attribute from the fo:block
it should be placed 2 cm right. WDYT?
Re: space-start and space-end for block-areas
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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
"left"!
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