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 "Peter B. West" <pb...@powerup.com.au> on 2001/01/21 08:20:29 UTC
large-allocation-rectangle of inline-area
The diagram AllocationRectInline-large.gif which illustrates the
large-allocation-rectangle of an inline-area in 4.2.3 Geometric
Definitions, appears to contradict the text. The text has:
The large-allocation-rectangle is the border-rectangle.
The diagram puts this rectangle in black around Spaces, outside the
Border Rectangle. In addition, in the distributed multi-file HTML set,
the diagram is incorrectly named, and does not appear in the text. (I
think the "large" was capitalised in the file name.)
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
before-intrusion-allowance
Posted by "Peter B. West" <pb...@powerup.com.au>.
Does anyone know what this is about? It is described in 4.4.2 Intrusion
Adjustments, and as far as I can tell, is never referred to again. It
seems to indicate that before-intrusion-allowance for a block includes
the sum of border-before-width and padding-before-width for all blocks
which are stacked preceding the block, and which are descendents of a
common ancestor reference-area. What is the purpose of this property?
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Adjacent edges in 4.2.5 Stacking Constraints
Posted by Karen Lease <kl...@club-internet.fr>.
Peter,
Yes, I believe you are right. The space is outside of the
border-rectangle (in this case the same as the allocation rectangle of
the contained area) and inside the content rectangle of the container.
-Karen
"Peter B. West" wrote:
>
> A question about the definition of adjacent edges in 4.2.5.
>
> The following definitions refer to the block-stacking-constraints.gif
> image. (Wouldn't it be useful to have numbered figures? Wouldn't it be
> useful to have an index?)
>
> Adjacent Edges with Block-stacking
> When A and B have a block-stacking constraint, the adjacent edges of A
> and B are an ordered pair recursively defined as:
> * In case 1, the before-edge of the content-rectangle of A and the
> before-edge of the allocation-rectangle of B.
> * In case 2, the after-edge of the content-rectangle of A and the
> after-edge of the allocation-rectangle of B.
>
> I don't have much of a grasp of this section, but shouldn't case 2 read:
> * In case 2, the after-edge of the allocation-rectangle of A and the
> after-edge of the content-rectangle of B?
>
> I.e., for contained areas, the appropriate relationship is between the
> content-rectangle of the containing area, and the allocation-rectangle
> of the contained area?
>
> Peter
> --
> Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
> "Lord, to whom shall we go?"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
> For additional commands, email: fop-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Adjacent edges in 4.2.5 Stacking Constraints
Posted by "Peter B. West" <pb...@powerup.com.au>.
There is a similar question concerning adjacent areas in the discussion
of inline-stacking constraints. The relevant image is
inline-stacking1.gif.
When A and B have an inline-stacking constraint, the adjacent edges of A
and B are an ordered pair defined as:
* In case 1, the start-edge of the content-rectangle of A and the
start-edge of the allocation-rectangle of B.
* In case 2, the end-edge of the content-rectangle of A and the
end-edge of the allocation-rectangle of B.
It seems that the content-rectangle and allocation-rectangle should be
reversed in case 2.
There is also something I cannot quite follow in the discussion of the
actual inline-stacking constraints. These constraints are said to
operate between pairs of inline-areas, or between an inline-area and a
line-area. This is clear enough in the case of a nested inline-area; it
can be contained in an inline-area or a line-area. Cases 1 and 2 cover
these possibilities.
The remainder of the discussion is concerned with cases 3a to 3e,
diagrams inline-stacking[234].gif. That discussion begins with: "A and
B are each either an inline-area or a line-area, ..."
Examples 3b to 3e involve two sequences of inline-areas, the first of
which includes A, the second of which includes B. These two areas (A &
B) are the "adjacent" members of their respective sequences in output
order. One or other of these sequences is contained in another area P.
In each case, P is defined as an inline-area, as is its contained area A
or B.
Given that "A and B are each either an inline-area or a line-area", P is
an inline-area, and the area contained in P is an inline-area, the
possibility must exist that the non-contained area, A or B, may be a
line-area. That leaves an inline-area adjacent to an line-area; i.e.,
either a line-area can be the child of a line- or inline-area, or an
inline-area can be a direct child of a block-area which is not a
line-area.
Arved asked a while ago whether, given that a "line-area is a special
kind of block-area whose children are all inline-areas" (4.2.1), all
inline-areas must be children of line-areas. The details of
inline-stacking constraints seem to allow the possibility that some are
not, but my feeling is that this does not make a lot of sense, because
of the orthogonality of the block progression and inline progression
directions, and the demand (4.2.1) that "a given area's children must
all be of one type."
Speaking of these examples involving areas A, B and P, something else
about the definitions of adjacency in inline-stacking constraints was
puzzling to me. The spec defines adjacency as an ordered pair, one of
which is the appropriate edge of the contained (A or B) area, the other
being one of the adjacent edges of the containing (P) and non-contained
(B or A respectively) areas. The principle seems to be that "adjacency"
is derived from the outside in. That is, resolve adjacency between
non-overlapping areas with stacking constraints first. The same
considerations apply to the examples of adjacency in the block-stacking
constraints. If something like that is indeed the case, a comment to
that effect at the beginning of the discussion would clarify the
definition for me, at least.
In Domino.
Peter
"Peter B. West" wrote:
>
> A question about the definition of adjacent edges in 4.2.5.
>
> The following definitions refer to the block-stacking-constraints.gif
> image. (Wouldn't it be useful to have numbered figures? Wouldn't it be
> useful to have an index?)
>
> Adjacent Edges with Block-stacking
> When A and B have a block-stacking constraint, the adjacent edges of A
> and B are an ordered pair recursively defined as:
> * In case 1, the before-edge of the content-rectangle of A and the
> before-edge of the allocation-rectangle of B.
> * In case 2, the after-edge of the content-rectangle of A and the
> after-edge of the allocation-rectangle of B.
>
> I don't have much of a grasp of this section, but shouldn't case 2 read:
> * In case 2, the after-edge of the allocation-rectangle of A and the
> after-edge of the content-rectangle of B?
>
> I.e., for contained areas, the appropriate relationship is between the
> content-rectangle of the containing area, and the allocation-rectangle
> of the contained area?
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Adjacent edges in 4.2.5 Stacking Constraints
Posted by "Peter B. West" <pb...@powerup.com.au>.
A question about the definition of adjacent edges in 4.2.5.
The following definitions refer to the block-stacking-constraints.gif
image. (Wouldn't it be useful to have numbered figures? Wouldn't it be
useful to have an index?)
Adjacent Edges with Block-stacking
When A and B have a block-stacking constraint, the adjacent edges of A
and B are an ordered pair recursively defined as:
* In case 1, the before-edge of the content-rectangle of A and the
before-edge of the allocation-rectangle of B.
* In case 2, the after-edge of the content-rectangle of A and the
after-edge of the allocation-rectangle of B.
I don't have much of a grasp of this section, but shouldn't case 2 read:
* In case 2, the after-edge of the allocation-rectangle of A and the
after-edge of the content-rectangle of B?
I.e., for contained areas, the appropriate relationship is between the
content-rectangle of the containing area, and the allocation-rectangle
of the contained area?
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Block-stacking constraint example in 4.2.5
Posted by "Peter B. West" <pb...@powerup.com.au>.
The tree node diagram at the beginning of the above example
(mantree.gif), I personally would prefer to see replaced by nested block
diagrams as are used (block-stacking-constraints.gif) to illustrate the
concept of block-stacking constraints. I.e., block diagrams including
the stacking constraints, and also the fence-after B which eliminates
the D-E constraint.
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: Typo in 4.2.5 Stacking Constraints
Posted by Arved Sandstrom <Ar...@chebucto.ns.ca>.
At 05:57 PM 1/21/01 +1000, Peter West wrote:
>There is a small typo in the above section. Compare b. and c.
>
>b. B is the first normal child of a block-area, B is not a line-area, P,
>there is no fence preceding P, A and P have a block-stacking constraint
>S', and S consists of S' followed by the space-before of B; or
>
>c. A is the last normal child of a block-area P, A is not a line-area,
>there is no fence following P, P and B have a block-stacking constraint
>S'', and S consists of the space-after of A followed by S''.
Yeah, you're right. 'P' is out of turn in para b.
Arved
Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Typo in 4.2.5 Stacking Constraints
Posted by "Peter B. West" <pb...@powerup.com.au>.
There is a small typo in the above section. Compare b. and c.
b. B is the first normal child of a block-area, B is not a line-area, P,
there is no fence preceding P, A and P have a block-stacking constraint
S', and S consists of S' followed by the space-before of B; or
c. A is the last normal child of a block-area P, A is not a line-area,
there is no fence following P, P and B have a block-stacking constraint
S'', and S consists of the space-after of A followed by S''.
Peter
--
Peter B. West pbwest@powerup.com.au http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org