Re: ISSUE-68 (tts:backgroundColor): Region content

Yes, after I sent my email, I realized the same problem, so the correct
answer is the second of your two options: "arrange for spacing after the
last child of block-area (1)".

If there is no such child, then one will need to be synthesized.

G.

On 4/27/09 5:19 AM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

> It was my first thought too, to increase the size of the block-reference-area,
> however I don't think that quite solves the problem, since its background
> color is set by the region. So, unless, I'm missing something and the
> block-area (1) would expand too, it seems to me that either we have to say the
> block-reference-area gets its background-color trait set by the <body>
> element, or we need to arrange for spacing after the last child of block-area
> (1) to force the blue rectangle to increase in size.
> 
> -----Original Message-----
> From: Glenn A. Adams [mailto:gadams@xfsi.com]
> Sent: 26 April 2009 3:45 AM
> To: Sean Hayes
> Cc: Public TTWG List
> Subject: Re: ISSUE-68 (tts:backgroundColor): Region content
> 
> 
> inline
> 
> On 4/25/09 6:28 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:
> 
>> Yes its difficult when we use the same terms in different vocabularies.
>> Thanks
>> for that exposition, it makes it easier for me to rephrase the question in
>> XSL
>> terms.
>> 
>> I'm concerned only with the semantics of this section:
>>        block-viewport-area        ; fo:block-container  < tt:region
>> tts:backgroundColor"red"
>>         block-reference-area      ; fo:block-container  < tt:region
>>          block-area   (1)         ; fo:block            < tt:body
>> tts:backgroundColor"blue"
>>           block-area   (2)        ; fo:block            < tt:div
>> 
>> If the block-area for body is not big enough to overflow the
>> block-viewport-area, then the background (let's say red for argument's sake)
>> is rendered on the viewport area.
> 
> [GA] Correct, per XSL 1.1 4.9.4, since background-attachment is not
> specified and has initial value of 'scroll' and since the refined
> block-progression-dimension of the block-reference-area is not larger than
> the block-progression-dimension of the block-viewport-area.
> 
>> So we have a red rectangle the size of the
>> region, now we need to inset into this by the padding and draw the content
>> area.
>> XSL defines that the block-reference-area and block-area (1) have a stacking
>> constraint, so the after-edge of the block-reference-area is after (in the
>> bpd) the after edge of block (1), also the two block areas have a similar
>> stacking constraint. We don't define any spacing after blocks, and the
>> default
>> is 0pt so in fact they are all effectively coincident.
> 
> [GA] Correct, per XSL 1.1 4.2.5 case 2 or 3c'.
> 
>> Thus since we said block (1) is not big enough to fill the viewport (let's
>> say
>> it fills 50% of the content area), there is a gap between the after edge of
>> the block-reference-area (which is blue by virtue of containing the blue
>> block-area (1)), and the content area after edge.
> 
> [GA] Correct, though it is more clear to elaborate the last "content area
> after edge" as "after edge of content-rectangle of block-viewport-area".
> 
>> This area is therefore red,
>> leading to the appearance (but not the reality) that the padding on the after
>> edge is larger than it should be. This is semantically correct, but
>> authorially confusing, especially to someone with a CSS background (A much
>> larger population than those with XSL background, and likely our target
>> audience) who would expect (as I did) the blue rectangle to fill the content
>> area.
>> 
>> So my take on this, as I come more from a CSS background is to define the
>> block-area (1) to in effectively be an infinite plane (this is what I was
>> equating to the CSS canvas for the purposes of timed text, although obviously
>> this is my own interpretation and not currently indicated by the
>> specification). This is possible in XSL by defining an arbitrary amount of
>> spacing between the after edge of block (2) and the after edge of block (1)
>> (although obviously we would need to define this as part of the conversion to
>> XSL-FO).
> 
> [GA] Note that XSL 1.1 6.5.3 does already say as much about
> fo:block-container:
> 
> "The block-progression-dimension of the reference-area is not
> constrained..."
> 
> However, this applies to the parent area of block-area (1) in this example.
> So it is the block-reference-area generated by tt:region that is effectively
> the "infinite plane". In contrast, the allocation-rectangle of block-area
> (1) generated by tt:body is constrained to the cumulative geometries of its
> children (since we don't permit margin, padding, or border on tt:body).
> 
>> Now the block-reference-area is forced by the stacking constraint to overflow
>> the viewport area. The background of the block-viewport-area is set to red;
>> coloring the padding region, the background of block (1) [blue] is drawn onto
>> the block-reference-area which is viewed through the block-viewport-area
>> (coincident with the content area), and the result is semantically correct
>> XSL, and visually as expected from a CSS viewpoint (and as non normatively
>> referenced by 7.7.2
>> http://www.w3.org/TR/REC-CSS2/colors.html#propdef-background-color)
> 
> [GA] As you point out, this can be achieved in XSL by specifying an
> appropriate space constraint S on the trailing edge that ends
> block-reference-area P (see XSL 4.2.5 last paragraph).
> 
> I believe this can be done by modifiying DFXP 9.3.3 (6) to synthesize the
> following properties on the fo:block generated by tt:body:
> 
> space-after.optimum="<region-bpd>"
> space-after.maximum="<region-bpd>"
> space-after.conditionality="retain"
> 
> where <region-bpd> is computed as follows:
> 
> if ( is-horizontal-writing-mode ( tt:region ) ) {
>   region-bpd := computed-height ( tt:region );
> } else if ( is-vertical-writing-mode ( tt:region ) ) {
>   region-bpd := computed-width ( tt:region );
> } else {
>   region-bpd := 0pt;
> }
> 
> This space constraint allows for a minimum of 0pt (the default) and optimum
> and maximum of the available extent in the block progression direction of
> the region. As such, it should ensure that there is sufficient whitespace
> content at the after edge of the block-area (1) generated by tt:region, and
> thus, fill out its content-rectangle to ensure the proper after padding
> dimension.
> 
> I will go ahead an adopt this as a resolution for this issue, but I also
> want to test it on an XSL formatter to make certain my interpretation is
> correct.
> 
> Glenn
> 
> 
>

Received on Monday, 27 April 2009 01:34:13 UTC