Listners,

I should have forwarded this at the time Karen sent the responses she 
had received.  Most of it is just fiddly bits, but for the record, 
herewith the XSL editors.

Peter
-- 
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"
Title: Disposition of Comments on XSL Candidate Recommendation

Disposition of Comments on XSL Candidate Recommendation

Comment 25 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0061.html

Date: Tue, 23 Jan 2001 11:09:28 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Fwd: Typo in 4.2.5 Stacking Constraints]

Forwarded on advice from Max Froumentin.

-------- Original Message --------
Subject: Typo in 4.2.5 Stacking Constraints
Date: Sun, 21 Jan 2001 17:57:38 +1000
From: "Peter B. West" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Dis
To: [EMAIL PROTECTED]
References: <3A681DEA.18886.840F8E@localhost>
<[EMAIL PROTECTED]>

Item 1

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''.

Disposition: Accepted (editorial)

The "P" in the first case has been moved to be after "block-area".

Peter
--
Peter B. West  [EMAIL PROTECTED]
"Lord, to whom shall we go?"

Comment 26 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0062.html

Date: Tue, 23 Jan 2001 11:11:13 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Fwd: Adjacent edges in 4.2.5 Stacking Constraints]



-------- Original Message --------
Subject: Adjacent edges in 4.2.5 Stacking Constraints
Date: Mon, 22 Jan 2001 22:47:12 +1000
From: "Peter B. West" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Dis
To: [EMAIL PROTECTED]
References:
<3A681DEA.18886.840F8E@localhost><[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

Item 1

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?

Disposition: Accepted (editorial)

Yes there is a typo in the spec.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 27 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0063.html

Date: Tue, 23 Jan 2001 11:11:09 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Fwd: large-allocation-rectangle of inline-area]

Forwarded on advice from Max Froumentin.

-------- Original Message --------
Subject: large-allocation-rectangle of inline-area
Date: Sun, 21 Jan 2001 17:20:29 +1000
From: "Peter B. West" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Dis
To: [EMAIL PROTECTED]
References: <3A681DEA.18886.840F8E@localhost>

Item 1

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.)

Disposition: Accepted (clarification)

The figure is very unclear and has been replaced with one where arrows indicate for each label which rectangle is meant.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 28 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0064.html

Date: Tue, 23 Jan 2001 11:12:06 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [Fwd: Block-stacking constraint example in 4.2.5]



-------- Original Message --------
Subject: Block-stacking constraint example in 4.2.5
Date: Mon, 22 Jan 2001 22:57:18 +1000
From: "Peter B. West" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Dis
To: [EMAIL PROTECTED]
References:
<3A681DEA.18886.840F8E@localhost><[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>

Item 1

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.

Disposition: Explanation of why no change will be made

The idea behind this form of the diagram is to emphasize that this relationship is deducible from the tree structure and trait values, not the geometric proximity of the areas.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 29 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0066.html

Date: Sat, 27 Jan 2001 07:13:42 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: 5.3.2 Margin, Space, and Indent Properties

Item 1

The above section seems to define the relationship between, say,
end-indent and padding/border/space-end shown in the diagram
RectsForModel.gif in 4.4.1 Stacked Block-areas.  I.e., end-indent =
padding-end + border-end + space-end, where, according to 5.3.2,
space-end has a corresponding margin property.  5.3.2 has
end-indent = margin-corresponding + padding-end + border-end-width

What does this do to the following announcement in 4.4.1?

   1. For each block-area B which is a descendant of P, the following
hold
      ....
    * the end-edge of its allocation-rectangle is parallel to the
end-edge
      of the content-rectangle of R, and offset from it inward by a
      distance equal to the block-area's end-indent plus its
      end-intrusion-adjustment (as defined below), minus its border-end,
      padding-end, and space-end value

Isn't that saying, "...a distance equal to the block-area's end-indent
plus its end-intrusion-adjustment minus its end-indent"?  That's what
the diagram seemed to indicate when I first read 4.4.1, and now, having
just read 5.3.2 (I'm a slow reader of specifications) that initial
impression is confirmed.  What am I missing?

Disposition: Explanation of XSL spec

Section 5.3.2 has an error in that one should also add inherited-*-indent to obtain the *-indent from the *-margin. (Murakami pointed this out in a posting to the editor's list).

Indents are "absolute" ie with respect to the containing reference area. Margins are with respect to the "containing block" and as such an indent is equal to the sum of the ancestor blocks' margins.

Changed text in the XSL recommendation:

start-indent = inherited_value_of(start-indent) + margin-corresponding + padding-corresponding + border-corresponding-width

end-indent = inherited_value_of(end-indent) + margin-corresponding + padding-corresponding + border-corresponding-width

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 30 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001JanMar/0067.html

Date: Sat, 27 Jan 2001 09:14:33 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: 5.3.3 Height, and Width Properties

Item 1

The above section has a number of paragraphs like:

    * If any of "height", "min-height", or "max-height" is
specified:
          * If "height" is specified then first set:
            block-progression-dimension.minimum=<height>
            block-progression-dimension.optimum=<height>
            block-progression-dimension.maximum=<height>
          *
            If "height" is not specified, then first set:
            block-progression-dimension.minimum=auto
            block-progression-dimension.optimum=auto
            block-progression-dimension.maximum=auto
          *
            Then, if "min-height" is specified, reset:
            block-progression-dimension.minimum=<min-height>
          *
            Then, if "max-height" is specified, reset:
            block-progression-dimension.minimum=<max-height>

Shouldn't the last read:
Then, if "max-height" is specified, reset:
block-progression-dimension.MAXimum=<max-height>
?

There are four such instances.

Disposition: Accepted (bug in spec)

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

Comment 35 (public comment): lists.w3.org/Archives/Public/xsl-editors/2001AprJun/0000.html

Date: Sat, 31 Mar 2001 00:20:08 -0500 (EST)
Message-ID: <[EMAIL PROTECTED]>
From: "Peter B. West" <[EMAIL PROTECTED]>
To: xsl-editors <[EMAIL PROTECTED]>
CC: fop-dev <[EMAIL PROTECTED]>
Subject: Ambiguities in XSL 1.0 spec

Item 1

6.4.14 fo:region-before

Areas:

The inline-progression-dimension of the region-viewport-area is
determined by the precedence trait on the fo:region-before. If the
value of the precedence trait is true, then the
inline-progression-dimension extends up to the
**start- and after-edges**
of the content-rectangle of the page-reference-area. In this case, the
region-before region-viewport-area acts like a float into areas
generated by the region-start and region-end.

Should `start- and after-edges' be `start- and end-edges'?

Likewise for 6.4.15 fo:region-after.

Disposition: Accepted (editorial)

7.12 Area Alignment Properties

Item 2

Diagram Baselines-rev.gif

Note position of text-before-edge and text-after-edge.  Discussion in
NOTE to text-before-edge for ideographic scripts seems to contradict
the diagram.

'For ideographic fonts, the position of this baseline is normally 1 EM
in the shift-direction from the "ideographic" baseline.'

In the diagram, possibly due to the presence of non-ideographic fonts,
the text-before-edge seems to be 1 EM in the shift-direction from the
text-after-edge, and inside the EM box which is based on the ideographic
baseline.

Disposition: Explanation of XSL spec

The "text-before-edge" and "text-after-edge" shown in the figure is, as is stated in the text, computed under the assumption that it is the "alphabetic" baselie that is the dominant-baseline. IF the assumption had been instead that it was the "ideographic" baseline then the edge would have been as you describe.

Item 3

The first NOTE to the discussion of after-edge is unclear.

'If all the inline-areas in a line-area are aligned to the "after-edge"
then the specification for the "before-edge" will set the "before-edge"
baseline to coincide with the "text-before-baseline" of the line. Then,
case (2) above will determine an offset to the "bottom-edge" baseline
that will align the "before-edge" of the area with the greatest height
to its allocation-rectangle to "before-edge" baseline.'

Perhaps something along the lines of:
'Then, case (2) above will determine the offset to  the "bottom-edge"
baseline so as to fit the area with the tallest allocation-rectangle (in
the block-progression direction.)  When the "after-edge" of that tallest
area is aligned to the "after-edge" baseline, the "before-edge" of the
area coincides with the "before-edge" baseline.'

Disposition: Accepted (editorial)

The sentence has been rewritten, but the formulation suggested by the commenter cannot be used verbatim as it mixes absolute-direction terms like "bottom" and "tallest" with the relative designations of "before-edge" and "after-edge".

Changed text in the XSL recommendation:

If all the inline-areas in a line-area are aligned to the "after-edge" then the specification for the "before-edge" will set the "before-edge" baseline to coincide with the "text-before-baseline" of the line. Then, case (2) above will determine the offset to the "after-edge" baseline. In this case the allocation-rectangle of one of the areas will extend from the "before-edge" baseline to the "after-edge" baseline.

Peter
--
Peter B. West  [EMAIL PROTECTED]  http://powerup.com.au/~pbwest
"Lord, to whom shall we go?"

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to