W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2009

[Bug 6267] space-start

From: <bugzilla@wiggum.w3.org>
Date: Thu, 15 Jan 2009 11:29:24 +0000
To: xsl-editors@w3.org
Message-Id: <E1LNQPc-0004QE-GJ@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=6267





--- Comment #5 from Vincent Hennebert <vhennebert@gmail.com>  2009-01-15 11:29:24 ---
(In reply to comment #3)
> The second part of the original message, concerning tables, is now Bug #6319.
> 
> The summary of this message was "Tables, space-start and border-separation" and
> is now "space-start".
> 
> The proposed resolution for space-start is:
> 
> ---------------------------------------------------------
> In the definition of properly stacked, in 4.4.1, replace the second and 
> third bullet points of condition 1 with:
> 
> ================
> * the start edge of its allocation-rectangle is parallel to the 
> start-edge of the content-rectangle of R (where R is the closest 
> ancestor reference-area of B), and offset from it inward by a distance 
> equal to the block-area's start-indent plus its 
> start-intrusion-adjustment (as defined below), minus its border-start, 
> padding-start, and start-edge margin values, and
> 
> * 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 end-edge 
> margin values.
> 
> By "start-edge margin" or "end-edge margin" value, we mean the value of 
> margin-left, margin-right, margin-top or margin-bottom, depending on 
> which corresponds to the start-edge or end-edge directions.
> ================

This does not seem to solve the uncertainty I'm afraid. The border-start is
already taken into account in the computation of the offset (“... start-indent
+ start-intrusion-adjustment, minus border-start...”). Would that mean that the
border should now be counted twice? This is very unlikely to match users
expectations I think.

The following re-writing of the second bullet point seems to be enough
actually:
“the start edge of its allocation-rectangle is parallel to the start-edge of
the content-rectangle of R (where R is the closest ancestor reference-area of
B), and offset from it inward by a distance equal to the block-area's
start-intrusion-adjustment (as defined below)”
and likewise for the second bullet.

Then formula (3) can be re-written like this:
(3a) xa = start-intrusion-adjustment
and combined with formula (2) (again in the simplified conditions where there
is no change of writing direction nor reference-orientation):
    xc = start-indent + start-intrusion-adjustment

In the common case where there is no start-indent nor
start-intrusion-adjustment, this means that the start-edge of the
content-rectangle coincides with the start-edge of the content rectangle of its
nearest ancestor reference area. Roughly speaking, the area's padding-start and
border-start ‘stick out’ in the margin, which is what most XSL-FO renderers
already implement, and matches user expectations.

This would mean that in the case of tables with the separate border model, the
first possibility in the attached image would be retained, since according to
section 6.7.10 half of the border-separation is associated to the cells'
borders, so lies inside the content-rectangle of the table.


> In the subsequent diagrams in 4.4.1, remove the references to 
> "Space-start" and "Space-end".
> 
> 
> In section 4.2.3, remove the word "Spaces" from the green background of 
> the first two diagrams.
> ---------------------------------------------------------
> 
> In accordance with the instructions at 
> http://www.w3.org/XML/2008/01/xsl-fo-bugzilla.html#verify, please review the
> proposed resolution carefully, and let the Working Group know whether it's
> acceptable or not.


Thanks,
Vincent Hennebert


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 15 January 2009 11:29:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 11:00:00 GMT