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 Karen Lease <kl...@club-internet.fr> on 2001/01/18 22:23:19 UTC
Re: fo:block-container, padding and borders- request for clarification
Max,
I'll be interested in what you decide. In the meantime, a new hot topic
has been raging in the fop-dev list (perhaps you've noticed.)
A few days ago I wrote:
<quote>
Is anyone else bothered by the fact that fo:inline and fo:basic-link can
contain "%block;" type FOs as children?
</quote>
A long discussion ensued, with several points of view being expressed.
My own feeling is that it's not clear what the layout should look like
in this case, and that if someone really wants to pile blocks into an
inline, then they should use inline-container. I can (almost) see the
use of such a construction for basic-link, which is a semantic concept
more than a layout one, but I don't see the use of it for fo:inline or
fo:bidi-override. It seems to me that the rules for block-area sizing
and positioning are incompatible with block-areas being placed inside a
normal inline-area.
Would it be possible to bring this question to the committee too (or
just enlighten me and the rest of the fop community if there is a clear
answer), or would you like me to submit it officially to the xsl-editors
mailbox?
Thanks for updating me,
Karen Lease
Max Froumentin wrote:
>
> Karen,
>
> We have reviewed your questions on fo:block-container and % values,
> and we decided that they required some thinking. So I can't give you
> any definite answer now but be assured that they'll be discussed at
> the next meeting (next week).
>
> Thanks for the feedback,
>
> Max.
> W3C XSL WG
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org
Re: text-depth and text-altitude
Posted by "Peter B. West" <pb...@powerup.com.au>.
Thanks Max. I shall do that in future.
Peter
Max Froumentin wrote:
>
> "Peter B. West" <pb...@powerup.com.au> writes:
>
> > Can I assume that the diagram InlineExampleMixed.2a.gif in Section 4.5,
> > which illustrates the nominal-requested-line-rectangle and the
> > maximum-line-rectangle, the definitions of text-altitude and text-depth
> > are reversed? That is the only way I can make sense of it.
>
> Thanks. I forwarded it to the editors. You may want to send those
> errors to xsl-editors@w3.org, otherwise we may miss it.
--
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: text-depth and text-altitude
Posted by Max Froumentin <mf...@w3.org>.
"Peter B. West" <pb...@powerup.com.au> writes:
> Can I assume that the diagram InlineExampleMixed.2a.gif in Section 4.5,
> which illustrates the nominal-requested-line-rectangle and the
> maximum-line-rectangle, the definitions of text-altitude and text-depth
> are reversed? That is the only way I can make sense of it.
Thanks. I forwarded it to the editors. You may want to send those
errors to xsl-editors@w3.org, otherwise we may miss it.
Max.
---------------------------------------------------------------------
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
large-allocation-rectangle of inline-area
Posted by "Peter B. West" <pb...@powerup.com.au>.
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
Re: text-depth and text-altitude
Posted by Fotis Jannidis <fo...@lrz.uni-muenchen.de>.
Peter,
I think you are right, the legends for text-altitude and and text-depth
in the diagram are reversed. In western scripts the text-altitude is
the height of a glyph above the baseline and the text-depth
specifies how far the glyph extends below the baseline. All
definitions in the spec I checked confirm this view.
Maybe the xsl editors should also include information on what are
the start-edge and the end-edge and what is the baseline-start-
point in this diagram.
Fotis
Other definitions:
4.6 Inline-areas:
An inline-area with inline-area children has a content-rectangle
which extends from its dominant baseline (see [4.2.6 Font
Baseline Tables]) by its text-depth in the block-progression-
direction, and in the opposite direction by its text-altitude;
7.26.4 "text-altitude"
Uses a value for the "height"of the font above the dominat
baseline
7.26.5 "text-depth"
Uses a value for the "depth"of the font below the baseline
From: "Peter B. West" <pb...@powerup.com.au>
> Chris,
>
> I'm missing something here. This is from 4.5 Line-areas.
>
> The nominal-requested-line-rectangle for a line-area is the rectangle
> ... whose before-edge is separated from the baseline-start-point by the
> text-altitude, and whose after-edge is separated from the
> baseline-start-point by the text-depth. It has the same
> block-progression-dimension for each line-area child of a block-area.
>
> The way I read that, the text-altitude is above (for Western systems)
> the baseline, and the text-depth is below. What goes on?
> >
> > > Can I assume that the diagram InlineExampleMixed.2a.gif in Section 4.5,
> > > which illustrates the nominal-requested-line-rectangle and the
> > > maximum-line-rectangle, the definitions of text-altitude and text-depth
> > > are reversed? That is the only way I can make sense of it.
>
> --
> 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: text-depth and text-altitude
Posted by "Peter B. West" <pb...@powerup.com.au>.
Chris,
I'm missing something here. This is from 4.5 Line-areas.
The nominal-requested-line-rectangle for a line-area is the rectangle
... whose before-edge is separated from the baseline-start-point by the
text-altitude, and whose after-edge is separated from the
baseline-start-point by the text-depth. It has the same
block-progression-dimension for each line-area child of a block-area.
The way I read that, the text-altitude is above (for Western systems)
the baseline, and the text-depth is below. What goes on?
Peter
Chris Ryland wrote:
>
> What's there makes sense to me.
> --
> Cheers!
> Chris Ryland
> Em Software, Inc.
> www.emsoftware.com
>
> ----- Original Message -----
> From: "Peter B. West" <pb...@powerup.com.au>
> To: <fo...@xml.apache.org>
> Sent: Thursday, January 18, 2001 7:43 PM
> Subject: text-depth and text-altitude
>
> > Can I assume that the diagram InlineExampleMixed.2a.gif in Section 4.5,
> > which illustrates the nominal-requested-line-rectangle and the
> > maximum-line-rectangle, the definitions of text-altitude and text-depth
> > are reversed? That is the only way I can make sense of it.
--
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: text-depth and text-altitude
Posted by Chris Ryland <cp...@emsoftware.com>.
What's there makes sense to me.
--
Cheers!
Chris Ryland
Em Software, Inc.
www.emsoftware.com
----- Original Message -----
From: "Peter B. West" <pb...@powerup.com.au>
To: <fo...@xml.apache.org>
Sent: Thursday, January 18, 2001 7:43 PM
Subject: text-depth and text-altitude
> Can I assume that the diagram InlineExampleMixed.2a.gif in Section 4.5,
> which illustrates the nominal-requested-line-rectangle and the
> maximum-line-rectangle, the definitions of text-altitude and text-depth
> are reversed? That is the only way I can make sense of it.
>
> 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
text-depth and text-altitude
Posted by "Peter B. West" <pb...@powerup.com.au>.
Can I assume that the diagram InlineExampleMixed.2a.gif in Section 4.5,
which illustrates the nominal-requested-line-rectangle and the
maximum-line-rectangle, the definitions of text-altitude and text-depth
are reversed? That is the only way I can make sense of it.
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: fo:block-container, padding and borders- request for clarification
Posted by Max Froumentin <mf...@w3.org>.
Karen Lease <kl...@club-internet.fr> writes:
> I'll be interested in what you decide. In the meantime, a new hot topic
> has been raging in the fop-dev list (perhaps you've noticed.)
Yes, I've seen it and passed it on the the rest of the working
group. So it's on the agenda for a future meeting. At the moment we're
very busy though, preparing the test suite for implementation tests
and also starting work on XSLT2. I'm doing my best so that you
implementors don't get too frustrated by the time it takes us to ack
your feedback or reply to your questions.
> Would it be possible to bring this question to the committee too (or
> just enlighten me and the rest of the fop community if there is a clear
> answer), or would you like me to submit it officially to the xsl-editors
> mailbox?
That's not necessary, as I moderate xsl-editors. Your question is now in
the queue!
I'll let you know asap.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org