Re: XSL CR WD Comments - Sections 4.1 through 4.2.5

Thanks to Glenn for his thoughtful comments.  Below is a description of how the new
draft addresses them--

Glenn Adams wrote:

> 1. 4.1, second note, has redundant "NOTE: " before "traits are also ...".

Done in tonight's draft.


> 2. 4.1, para 5 (not counting notes as paras), suggest removing "areas on" from
> "its glyphs distributed into areas on two separate line-areas".

Anders doesn't agree.


> 3. 4.1, next to last para, what is meaning of "values" in "one or more values
> constructed by the formatter" and what is meaning of "calculation formula"?

I don't agree; it's impossible to say everything in an introduction.


> 4. 4.2.1, para 2, should glyph areas be permitted to have sub-areas to
> accommodate diacritics and other complex construction of glyph shapes from
> multiple sub-glyph shapes?

That would be a glyph rendering issue and outside the scope of the XSL spec.


> 5. 4.2.2, para 4, talks about viewport/reference pair where start and end edges
> of content rectangles align. I read this as handling scrolling in block
> progression direction. How about scrolling in inline progression direction?

I don't understand where that reading comes from, since it also implies that the
before- and after-edges are parallel.


> 6. 4.2.2, para 5, has "Each element has the traits ..." which should read "area"
> instead of "element".

Yes, done in tonight's draft.


> 7. 4.2.2, last bullet after "Other traits include", has "character descendants
> of the area"; shouldn't this read "glyph" instead of "character"?

It means "character descendants of the area's generating formatting object", and has
been worded that way in the new draft.


> 8. 4.2.2, last para, has "traits of a formatting object"; shouldn't this read
> "properties of ...".

No, this is after refinement.


> 9. 4.2.3, para 1, suggest adding example showing when marks may appear outside
> the content rectangle.

I don't think it's worth an example. If it's absolutely impossible to understand the
sentence without another example or diagram, I'd take the sentence out.


> 10. 4.2.5, para 4, uses "space-specifiers", which hasn't been defined yet.

Forward reference is now included in the new draft.


> 11. 4.2.5, para 4, sub-item (1) and (2) discuss space-before and space-after,
> which haven't been defined yet.

See 4.2.2.


> 12. 4.2.5, note after figure "Adjacent Edges with Block-stacking", remove "in
> two places" due to redundancy.

I don't agree.


> 13. 4.2.5 second para after figure "Block-Stacking Constraint Example", which
> starts with "Inline-stacking Constraints." should have this prefix as a new
> heading for an un-numbered sub-section. Same for "Block-stacking Constraints" at
> start of 4.2.5 which should be a new heading.

Well, we've sort of done this in the new draft.


> 14. 4.2.5, the use of before and after in "fence-before" and "fence-after" does
> not align with the general uses of before and after in the remainder of the
> document meaning edges perpendicular to the block progression direction. In the
> present context, "before" and "after" are used as "start" and "end" are used
> elsewhere in the document.

How about "fence preceding P" and "fence following P"?


> 15. 4.2.5, para 3 (starting "If P is a block-area, ...") and second para under
> "Inline stacking constraints" (starting "If P and Q have an inline-stacking
> constraint ...", I would recommend a close comparison of the forms of these two
> paragraphs and that they be written in the same form, mutatis mutandis.

No. The form is more complicated for inline-areas for a reason. Inline-areas have to
worry about bi-directional text. On the other hand there is no reason to make the
block-area paragraph be more complex simply to match the inline-area paragraph.


> 16. 4.2.5, example 3b above "Adjacent Edges with Inline-Stacking 2", seems to
> have the label "A" pointing at the wrong area.

Yes, the figure will be fixed.


Regards,
 -- JeffC

******************************************************
Dr. Jeffrey L. Caruso <jcaruso@pageflexinc.com>
Pageflex, Inc.  215 First St.  Cambridge, MA 02142
(A Bitstream company)

Received on Friday, 10 November 2000 13:57:05 UTC