--- Jeremias Maerki <[EMAIL PROTECTED]> wrote:

> I'm afraid that you're wrong here. It's true that
> s-p-m and region-body
> don't directly generate reference areas but they
> also can't, because
> they are only used as a template for each new page.

Jeremias, so you are in agreement with me that they
are type (3) below -- not type (1).  The spec is very
clear on that.  These FO's are *used to generate a
area*, they don't *generate them* directly.  Hence you
are using the wrong equations to determine their
values.  They do *not* generate reference areas,
unlike what you were basing your logic on in your
previous email.

> For for each page
> they serve as FOs that generate reference areas.

Please use the official Rec terminology:  "they are
used to generate reference areas"  (type 3).  (If you
get vague, then your solutions become in danger of
getting inaccurate.)

> But let me give you another example where this is
> clearer and so you see
> that your argument doesn't really count in this
> discussion. Please open
> test/layoutengine/testcases/block-container3.xml.

> You can't
> deny that block-container generates a reference area
> directly. 

I'm not denying that at all.  But we are determining
the value of these properties on fo:region-body and
fo:simple-page-master, we are *not* resolving these
properties on fo:block-container.  Fo:block-container
uses these properties after they are already
calculated on fo:region-body and fo:s-p-m.  You are
jumping ahead here--the calculated values of these
properties on fo:s-p-m and fo:region-body is what the
point of your email was, and that is what I was
responding to.  Let's get these calculated values on
fo:r-b and fo:s-p-m nailed down before we discuss
their further usage within an fo:page-sequence.

This section of the spec, 5.3.2, Jeremias, and your
email I responded to, was just to determine the
calculated values on these two FO's:  fo:s-p-m and
fo:r-b.  This can be done, and their values would be
the same, regardless of whether those values are
subsequently activated within a page-sequence.  

>So in
> this test case the block inside the b-c has an
> effective start-indent of
> 20pt (10pt + 10pt) much like in Luca's example.
> If you look at the checks at the end of
> block-container3.xml you will
> realize that there is no "20000" (millipoints)
> anywhere. It's simply the
> effect from the reference area which results in the
> double indent. So if
> you wanted to have both text-generating blocks
> left-aligned at the same
> position you'd have to specify start-indent="0pt" on
> the block-container
> or on its nested block to reset the start-indent to
> "0pt".

This has nothing to do with the discussion.  We're
talking about the resolved values directly on fo:s-p-m
and fo:region-body.  That's all I was responding to:
your previous email.  You are using the wrong
equations to determine their calculated values,
because you incorrectly assumed that those FO's
(fo:s-p-m and fo:r-b) generate reference areas.

> > 
> > Section 6.1 [1] says "There are three kinds of
> > formatting objects: (1) those that generate areas,
> (2)
> > those that return areas, but do not generate them,
> and
> > (3) those that are used in the generation of
> areas."
> > 
> > fo:s-p-m and fo:region-body are type (3), not type
> > (1).
> > 
> > fo:s-p-m text:  The fo:simple-page-master
> formatting
> > object generates no area directly. It is used in
> the
> > generation of pages by an fo:page-sequence. type
> (3)
> > 
> > fo:r-b text:  The fo:region-body formatting object
> is
> > used to generate one region-viewport-area and one
> > region-reference-area whenever an
> > fo:simple-page-master that has an fo:region-body
> as a
> > child is used to generate a page.  (i.e., type 3)
> > 
> > 
> > [1]
> >

This IMO is the fatal flaw in your logic in your
previous email.  You determined fo:s-p-m and fo:r-b to
be type (1) FO's, and hence used the wrong equations
in 5.3.2 to determine calculated values for them. 
They are type (3) FO's, and hence the first two
equations can never be relevant for them.

> > 
> > 
> > > So in your case you could specify
> > > a margin="0pt" on
> > > the region-body which triggers the first formula
> > > given in 5.3.2. 
> > 
> > Again, I don't think so because fo:region-body
> never
> > generates a reference-area.  Hence, with no
> explicit
> > specification of margin properites, the third set
> of
> > formulas then activates:
> > 
> > margin-corresponding = start-indent -
> > inherited_value_of(start-indent) -
> > padding-corresponding - border-corresponding-width
> > 
> > with the additional rule that:  "If the
> "start-indent"
> > or "end-indent" properties are not specified their
> > inherited value is used in these formulae."
> > 
> > Since start-indent and end-indent were not
> specified,
> > then we have:
> > 
> > margin-corresponding =
> > inherited_value_of(start-indent) -
> > inherited_value_of(start-indent) -
> > padding-corresponding -
> border-corresponding-width,
> This formula is only used to calculate
> margin-corresponding. It is not
> used to calculate the effective indent.

They're the same thing for fo:s-p-m and fo:r-b, we
just determined that they are corresponding
properties.  This formula set--the third--is the only
one of the three in 5.3.2 that can be relevant for
determining the calculated values on fo:s-p-m and
fo:region-body, because neither of them generate
reference areas.  Hence, you are incorrect in using
the first and second formulas in trying to determine
the calculated values of these properties on these
FO's.  The first and second formulas require that the
FO in question be a type 1 FO.

> Corresponding properties should
> not be used directly to do the actual calculations
> that define the
> layout. Ask yourself: How would you decide when to
> use what property to
> calculate the actual indents? That's why the
> formulas are there to
> derive start|end-indent from the corresponding
> properties. The formula
> you're refferring to here is actually used inside
> IndentPropertyMaker.
> It is used to create the "margin-corresponding"
> value which is used in
> the formula sets 1 and 2.

You're jumping ahead where you don't need to,
confusing the situation.  We are discussing the
calculated values of these properties on fo:s-p-m and
fo:region-body.  That's it.  While you may be correct
with the above, we need to get the foundation of your
original argument--the calculated values of
start-indent and end-indent on fo:r-b--correct before
proceeding further.

> > or zero for the margin properties on
> fo:region-body. 
> > (i.e., we just rely on the 50pt. on
> > simple-page-master.)
> > 
> > So Luca is correct that both
> fo:simple-page-masters
> > should generate the same overall margins of 50 pt.
> > each, no?
> No. :-)

Jeremias, in order to persuade me--and RenderX,
apparently--on the calculated values on fo:s-p-m and
fo:r-b, you will need to rewrite this email [1],
keeping the logic as similar as you can, but without
(1) saying that fo:s-p-m and fo:r-b generate reference
areas or (2) hence ever choosing either of the first
two sets of equations in order to determine calculated
values on these two FO's.  Then we can go on and have
the above discussion.  You may yet prove me wrong. 
But first you have to clear up these previous errors. 
(You do *not* need to resort to subsequent usage of
these FO's in order to determine these calculated
values on these two FO's, so please don't confuse the
situation by doing so.)

Just as I previously debated you after first clearing
up where I was wrong--that margin-left and
start-indent aren't CP's--I need you to first clear up
your original email logically before we can proceed. 

In particular, these two sentences needs to be

1: "Now, because start|end-indent are inherited,
region-body also starts with a start-indent and
end-indent of 50pt which together with the
parent's start-indent accumulates 100pt because each
of the FOs are generating a reference area."

But *neither* generate a reference area--so please use
different equations in 5.3.2 (i.e., the third set is
your only option) to determine their values on these
two FO's.

2: "So in your case you could specify a margin="0pt"
the region-body which triggers the first formula given
in 5.3.2. If you don't specify margin the inherited
value for start-indent is used."

The first formula set (as well as the second) can
*never* be triggered for fo:region-body because this
FO never generates a reference area (or any area for
that matter--it is a type 3 FO, not type 1.)  You're
back to the third formula set again.

Sorry for the long post.


Reply via email to