Margin properties on region-body

[kl...@club-internet.fr]

Dear editors,

I've got some questions about the properties used to specify the
position of the region-body.

Most of the discussion in 6.4.13, as well as the illustration, uses the
"absolute" property names "margin-top", "margin-left", etc. to describe
the positioning of the region-body viewport rectangle relative to the
page-reference-area. However, the relative property names are also used,
for example:

"The inline-progression-dimension of the region-viewport-area is
determined by the inline-progression-dimension of the content-rectangle
of the page-reference-area minus the values of the start-indent and
end-indent traits of the region-master. ...

The block-progression-dimension of the region-viewport-area is
determined by the block-progression-dimension of the content-rectangle
for the page-reference-area minus the values of the space-before and
space-after traits of the region-master."

In theory, I find the use of the relative properties preferable, given
that the indents on the region-body are intended to leave space for the
side regions which are named using the writing-mode relative terms
(based on the writing-mode specified on the simple-page-master.)

However there a couple of slightly strange things involved with using
space-before/after and start/end-indent. It would be clearer to use
margin-start, etc, but I suppose you don't want to invent more
properties which aren't generallly useful (quite understandable.)

However the space properties are ranges rather than Lengths, whereas the
margin is a Length value. The obvious solution is to specify that
space-xxx.optimum will be used as the margin value.

Aside from the fact that the use of indent to specify page-master region
offsets doesn't feel very intuitive to me, the fact that indent is an
inherited property would seem to lead to unwanted behavior. Consider the
following case:

Neither start-indent nor the corresponding margin is specified on
region-body, but since start-indent is inherited, we look for a value on
the parent FO which is the simple-page-master. There we may well find a
value for the corresponding margin property. But this is clearly not
what is wanted!

I would suggest that when looking for a value for start-indent (or
end-indent), the inheritance hierarchy be broken at the first ancestor
FO which creates reference areas. In this case, this means that since
the parent of the region-body is a the s-p-m which creates reference
areas, the initial value (0) for start-indent is returned and not the
value of start-indent (or margin-x) on the s-p-m.

In fact, I believe this is a general principle concerning indent. For
example, a table can have indent which positions the table. But that
indent shouldn't generally be propagated to the table contents, since
table and table-cell are reference areas. 

Thank you for considering these issues,

Karen Lease
FOP'er
Senior Software Developer/Consultant
SPX Valley Forge


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Clarification of reference-orientation

[Arved Sandstrom <Ar...@chebucto.ns.ca>]

Hi, editors,

1. All mentions of "reference-orientation" inheritance in the spec say
something like "yes (see prose)". This includes Property Table Parts I and
II in the Property Summary, and Section 7.20.3.

The latter (the property description) indicates that the
reference-orientation _trait_ on an area is _indirectly_ derived from the
corresponding property on the FO that generated that area. Presumably this
alludes to Section 5.5.2, which states that

"The reference-orientation trait is copied from the reference-orientation
property during refinement. During composition an absolute orientation is
determined (see Section 4.2.2 - Common Traits on page 14)."

and in Section 4.2.2 it says

"If the reference-orientation for an area is 0, then the top, bottom, left,
and right edges of the content are parallel to those of the area's parent
and consistent with them. Otherwise the edges are rotated from those of the
area's parent as described in Section 7.20.3 - 'reference-orientation' on
page 283."

I want to clarify that this process of determining an absolute orientation
for the _area_ is not confused with being a "computed value" for the
purposes of inheritance. Because a computed value for inheritance is the
computed value of an FO property, not the value of a trait.

2. I would like to clarify the inheritance  and trait derivation process,
particularly for the simple-page-master/region level.

Example 1: let's assume that a simple-page-master has a
reference-orientation of -90. This means that the TOP of the
page-reference-area is at 3 o'clock. The margin-top for the region-body is
at 3 o'clock, the margin-left is at 12 o'clock, the margin-right is at 6
o'clock, and the margin-bottom is at 9 o'clock.

If the region-body has no explicit specification of reference-orientation
then the spec tells me that the reference-orientation is -90 as inherited
from the simple-page-master. As a result, the region-reference-area is now
oriented with _its_ TOP at -180 (or 180, or 6 o'clock).

Is this correct? My reading of the spec tells me that the _indirect_
derivation alluded to above is merely the process of determining for the
latter case that TOP for the region-body is at 180, that is, the absolute
orientation is 180.

I am confused, perhaps needlessly so, by the addition of the "see prose" in
reference to inheritance of this property. Why is it there? There is no
complication about inheritance of this property; the computed value of the
_property_ is the same as the _specified_ value; what the _trait_ on the
_area_ is determined to be is something else entirely.

Example 2: let's assume that a top-level block-container specifies 90 for
the value of "reference-orientation", and that the region-body TOP that
applies is also 90. What is the computed value for the reference-orientation
_property_ on the block-container? Is it 90 or 180? I interpret the spec as
saying that it is 90, and that if there was a nested block-container or
inline-container with no explicit specification it would inherit 90. The
_absolute orientation_ of the top-level block-container is 180, but this is
a trait.

Or is the "see prose" a suggestion that in fact the computed value on the
top-level block-container is 180? And that this is what potential descendant
block-containers or inline-containers would inherit? I hope not. I actually
don't think you mean this, but that "see prose" has thrown me for a loop.
:-)

Clarification welcome.

3. Why the different language when talking about reference-orientation for
region-before, region-after, region-start and region-end? I mean this:

"The reference-orientation of the region-viewport-area is taken from the
value of the reference-orientation trait on the region-master which
specifies the region. reference-orientation of the region-reference-area is
set to "0" and is, therefore, the same as the orientation established by the
region-viewport-area."

This language is not used elsewhere. Section 6.4.13 says:

"The reference-orientation trait of the fo:region-body is used to orient the
coordinate system of the region-reference-area generated by the
fo:region-body relative to the coordinate system of the page-reference-area
generated by fo:simple-page-master (and, therefore, relative to the viewport
positioned in that latter coordinate system)."

and Sections 6.5.3 and 6.6.8 say nothing special at all. Is this
significant? Just curious.

Regards,
Arved Sandstrom


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org