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

Reply via email to