search

w3c / ttml1

Timed Text Markup Language 1 (TTML1)
http://w3c.github.io/ttml1/
Other
13 stars 12 forks source link

Do tts:origin and tts:extent apply to the padded rectangle or the content rectangle? #221

Closed palemieux closed 7 years ago

palemieux commented 8 years ago

TTML specifies:

The definition of tts:padding implies that padding is included in the region area ("inset"), and thus tts:origin is the top-left coordinate of the region rectangle including padding, and tts:extent is the width of the region including padding.

However, the semantics of tts:padding are based on XSL, which states that:

Since the content-rectangle specifically excludes padding (Section 4.4.1), XSL/CSS positioning and sizing do not include padding.

Do tts:origin and tts:extent apply to the padded rectangle or the content rectangle?

For instance, given a <region> with tts:extent="100px 100px", does applying tts:padding=20px result in (a) a region with an effective tts:extent="140px 140px" or (b) an area available for text flow that is 60px by 60px?

Suggest defining "region area" explicitly in TTML and explicitly specifying relationship with XSL/CSS content and padding rectangles.

skynavga commented 8 years ago

Do tts:origin and tts:extent apply to the padded rectangle or the content rectangle?

They apply to the border rectangle, or, to put it another way, they define an allocation rectangle into which border, padding, and content are placed.

I don't consider the current spec text (in TTML[12]) a bug, but I agree it is underspecified with respect to TTML usage. So I'm marking this as an enhancement rather than a bug.

nigelmegitt commented 8 years ago

I have always thought that it is clear that tts:origin and tts:extent on region specify the area and that padding is inset from this area, resulting in a smaller effective area available for text flow. This is clearly what is shown in the example, and it was my interpretation of the parenthetical"(inset)" in the first paragraph of the section on tts:padding - it seems that @palemieux has read through the references more carefully than I have though!

andreastai commented 7 years ago

Is there a corresponding concept in XSL-FO and CSS where padding actually "shrinks" the content rectangle? I had always (the possibly wrong) assumption that extent defines the content rectangle (excluding padding and border). I thought that a region can be compared to an XSL formatting object of a block or block container where you may set the corresponding properties of width and height. As I understood padding is not included in this values.

skynavga commented 7 years ago

It is clear from the examples in TTML1 that the extent of a region includes padding, i.e., it is an inset and not an outset. See [1] and

The tts:padding attribute is used to specify padding (or inset) space on all sides of a region area.

This effectively means that the allocation rectangle for body is the extent of the region minus any padding defined on the region. In TTML2, we will add border thickness (of region) to these insets.

[1] https://www.w3.org/TR/ttaf1-dfxp/#style-attribute-padding

andreastai commented 7 years ago

The tts:padding attribute is used to specify padding (or inset) space on all sides of a region area.

Padding is an inset space with reference to the border of an area (and therefore distinguishes from margin in CSS or space added to an area in XSL-FO). But the important part is its relation to width and height defined for an area.

In XSL-FO and CSS width and height refer to the content rectangle, not the allocation rectangle. In TTML 1 Section 9.3.3 Synchronic Flow Processing origin and extent are mapped to the top, left, bottom and right attributes of an XSL-FO block-container (although later in the examples extent they are mapped to width and height). In XSL-FO these attributes (or later the properties of the formatting objects) refer to the position of the content-rectangle of the associated area. Padding values are mapped, as attributes where a corresponding XSL-FO property exist, after top, bottom, left and right have been set.

Extent shall also not include padding for another reason: if padding is expressed in percentage this should be relative to width and height of a region. If padding would be part of the width and height this would be a circular reference.

I think that therefore the images in TTML 1 are incorrect and should be amended.

skynavga commented 7 years ago

I'm sorry, but your interpretation is incorrect and at odds with implementations going back to the beginning of DFXP. See below.

On Sun, Dec 11, 2016 at 9:11 AM, Andreas Tai notifications@github.com wrote:

The tts:padding attribute is used to specify padding (or inset) space on all sides of a region area.

Please note the word "inset" as opposed to "outset". In TTML1, padding only applies to region, and padding is defined as an inset on regions. If region extent was the content rectangle for the region, then padding on region would extend outside of the extent, and thus be an outset. Furthermore, the background color of the region would extend outside the extent. This is clearly not the intended behavior.

Padding is an inset space with reference to the border of an area (and therefore distinguishes from margin in CSS or space added to an area in XSL-FO). But the important part is its relation to width and height defined for an area.

In XSL-FO and CSS width and height refer to the content rectangle, not the allocation rectangle. In TTML 1 Section 9.3.3 Synchronic Flow Processing https://www.w3.org/TR/ttaf1-dfxp/#semantics-region-layout-step-2 origin and extent are mapped to the top, left, bottom and right attributes of an XSL-FO block-container (although later in the examples extent they are mapped to width and height). In XSL-FO these attributes (or later the properties of the formatting objects) refer to the position of the content-rectangle of the associated area https://www.w3.org/TR/xsl/#left. Padding values are mapped, as attributes where a corresponding XSL-FO property exist, after top, bottom, left and right have been set.

Extent shall also not include padding for another reason: if padding is expressed in percentage this should be relative to width and height of a region https://www.w3.org/TR/ttaf1-dfxp/#style-attribute-padding. If padding would be part of the width and height this would be a circular reference.

I think that therefore the images in TTML 1 are incorrect and should be amended.

The images are correct, but you do point out a discrepancy that needs addressed, namely, that TTML1 needs an errata (and TTML2 needs the same language) that makes it clear that, exceptionally, extent on region means allocation rectangle inside of which a region's border rectangle > padding rectangle > content rectangle are allocated.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/ttml1/issues/221#issuecomment-266290543, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCbzVBosm-w7YYUHEuDDoBbwcjXMlLks5rHCCegaJpZM4KwkdJ .

andreastai commented 7 years ago

I'm sorry, but your interpretation is incorrect and at odds with implementations going back to the beginning of DFXP.

To see padding as part of the defined width and height of a block is conceptually at odds with XSL-FO and CSS.

If region extent was the content rectangle for the region, then padding on region would extend outside of the extent, and thus be an outset.

As mentioned above I see "inset" referring to the "border" of the region's area. If width and height are set for elements that represent XSL-FO formatting objects in XSL-FO or boxes in CSS they always refer to the content rectangle (XSL-FO) or content area (CSS). Both concepts do not include padding.

How do you solve the below when padding is part of the extent?

Extent shall also not include padding for another reason: if padding is expressed in percentage this should be relative to width and height of a region https://www.w3.org/TR/ttaf1-dfxp/#style-attribute-padding. If padding would be part of the width and height this would be a circular reference.

Do you propose that width and height of a region are different from its extent? This would be really confusing.

nigelmegitt commented 7 years ago

Following the XSL 1.1 references in TTML1 through to the CSS references gets me to https://www.w3.org/TR/REC-CSS2/box.html#box-dimensions which defines the width and height:

The dimensions of the content area of a box -- the content width and content height -- depend on several factors: whether the element generating the box has the 'width' or 'height' property set, whether the box contains text or other boxes, whether the box is a table, etc. Box widths and heights are discussed in the chapter on visual formatting model details.

The box width is given by the sum of the left and right margins, border, and padding, and the content width. The height is given by the sum of the top and bottom margins, border, and padding, and the content height.

Percentage values for padding clearly relate to the containing block's width and height. In the case of TTML's region element the natural equivalent of the containing block would be the root container region rather then the region itself. This does seem to me like an inconsistency between TTML1 and XSL-FO/CSS.

skynavga commented 7 years ago

On Mon, Dec 12, 2016 at 12:36 AM, Andreas Tai notifications@github.com wrote:

I'm sorry, but your interpretation is incorrect and at odds with implementations going back to the beginning of DFXP.

To see padding as part of the defined width and height of a block is conceptually at odds with XSL-FO and CSS.

In the first place, tts:extent is not defined by XSL-FO or CSS. We (TTWG) invented it. And we intended (though possibly failed to properly specify) that in the case of region, it defines the width and height of the allocation rectangle into which a container block (area) is formatted, and, in particular, that this allocation rectangle fully contains the border rectangle (and padding rectangle) of the region.

If region extent was the content rectangle for the region, then padding on region would extend outside of the extent, and thus be an outset.

As mentioned above I see "inset" referring to the "border" of the region's area. If width and height are set for elements that represent XSL-FO formatting objects in XSL-FO or boxes in CSS they always refer to the content rectangle (XSL-FO) or content area (CSS). Both concepts do not include padding.

Please refer to the figure at [1]. The intent of extent on region is to define a rectangle that effectively corresponds with a border rectangle, inside of which is a padding rectangle, inside of which is a content rectangle. In TTML1 we had no border on region, so the border and padding rectangles correspond. In TTML2, we have added border to region, so now we have the possibility of distinct border and padding rectangles.

In the more general TTML2 sense, we now have border rectangle on region being formatted according to the computed value of tts:border on the region, and we have padding rectangle on region being formatted according to the computed value of tts:padding on the region, and we have content rectangle on region being forrmatted according to the children of region (in the ISD sense restructuring), which, since body is the only child, that means the content rectangle of the region is where body is formatted, which, in turn may (in TTML2 only) have its own border and padding.

[1] https://www.w3.org/TR/xsl/#area-intro

Your assertion that extent on region should apply to the content rectangle of region effectively makes that extent correspond to the allocation rectangle for body, and places any region padding and border outside the region extent (as an outset). This is very clearly not the intent of the TTWG (during the development of DFXP and TTML1) where there was a clear, shared understanding that a region's extent contains all possible rendered marks unless tts:overflow="visibile" and overflow from the region's content rectangle (i.e., body) occurs.

How do you solve the below when padding is part of the extent?

Extent shall also not include padding for another reason: if padding is expressed in percentage this should be relative to width and height of a region https://www.w3.org/TR/ttaf1-dfxp/#style-attribute-padding. If padding would be part of the width and height this would be a circular reference.

This is not a problem, because in this context, "width and height of region" means "width and height of a region's extent" which means "width and height of a region's allocation rectangle" which means "width and height of a region's border rectangle". Since this width and height is already known when resolving the value of tts:padding,at least in TTML1, then this doesn't present any problem. It does suggest, however, that we clarify the language here regarding "width and height of region".

Do you propose that width and height of a region are different from its

extent? This would be really confusing.

I'm not proposing anything. I'm explaining what the authors of TTML1 intended, whether they were successful in conveying that intent correctly. The width and height of a region in this context means the width and height components of the resolved value of tts:extent which semantically corresponds to the width and height of the region's border rectangle, and not its content rectangle.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/ttml1/issues/221#issuecomment-266361443, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCb-QjtnIldd-1wHErrEYLqk2gCuicks5rHPmKgaJpZM4KwkdJ .

skynavga commented 7 years ago

I should also add that there may be some confusion about the terms width and height. We have avoided making use of these terms in names in the TTML specs because of the possible for multiple levels of ambiguity, e.g., whether width and height are writing system relative or not, which rectangle they apply to, etc.

With regard to the content rectangle dimensions, we now have tts:ipd and tts:bpd properties (which are basically congruent to the width and height properties in CSS). However, these properties do not apply to region, but only content elements.

On Mon, Dec 12, 2016 at 12:51 PM, Glenn Adams glenn@skynav.com wrote:

On Mon, Dec 12, 2016 at 12:36 AM, Andreas Tai notifications@github.com wrote:

I'm sorry, but your interpretation is incorrect and at odds with implementations going back to the beginning of DFXP.

To see padding as part of the defined width and height of a block is conceptually at odds with XSL-FO and CSS.

In the first place, tts:extent is not defined by XSL-FO or CSS. We (TTWG) invented it. And we intended (though possibly failed to properly specify) that in the case of region, it defines the width and height of the allocation rectangle into which a container block (area) is formatted, and, in particular, that this allocation rectangle fully contains the border rectangle (and padding rectangle) of the region.

If region extent was the content rectangle for the region, then padding on region would extend outside of the extent, and thus be an outset.

As mentioned above I see "inset" referring to the "border" of the region's area. If width and height are set for elements that represent XSL-FO formatting objects in XSL-FO or boxes in CSS they always refer to the content rectangle (XSL-FO) or content area (CSS). Both concepts do not include padding.

Please refer to the figure at [1]. The intent of extent on region is to define a rectangle that effectively corresponds with a border rectangle, inside of which is a padding rectangle, inside of which is a content rectangle. In TTML1 we had no border on region, so the border and padding rectangles correspond. In TTML2, we have added border to region, so now we have the possibility of distinct border and padding rectangles.

In the more general TTML2 sense, we now have border rectangle on region being formatted according to the computed value of tts:border on the region, and we have padding rectangle on region being formatted according to the computed value of tts:padding on the region, and we have content rectangle on region being forrmatted according to the children of region (in the ISD sense restructuring), which, since body is the only child, that means the content rectangle of the region is where body is formatted, which, in turn may (in TTML2 only) have its own border and padding.

[1] https://www.w3.org/TR/xsl/#area-intro

Your assertion that extent on region should apply to the content rectangle of region effectively makes that extent correspond to the allocation rectangle for body, and places any region padding and border outside the region extent (as an outset). This is very clearly not the intent of the TTWG (during the development of DFXP and TTML1) where there was a clear, shared understanding that a region's extent contains all possible rendered marks unless tts:overflow="visibile" and overflow from the region's content rectangle (i.e., body) occurs.

How do you solve the below when padding is part of the extent?

Extent shall also not include padding for another reason: if padding is expressed in percentage this should be relative to width and height of a region https://www.w3.org/TR/ttaf1-dfxp/#style-attribute-padding. If padding would be part of the width and height this would be a circular reference.

This is not a problem, because in this context, "width and height of region" means "width and height of a region's extent" which means "width and height of a region's allocation rectangle" which means "width and height of a region's border rectangle". Since this width and height is already known when resolving the value of tts:padding,at least in TTML1, then this doesn't present any problem. It does suggest, however, that we clarify the language here regarding "width and height of region".

Do you propose that width and height of a region are different from its

extent? This would be really confusing.

I'm not proposing anything. I'm explaining what the authors of TTML1 intended, whether they were successful in conveying that intent correctly. The width and height of a region in this context means the width and height components of the resolved value of tts:extent which semantically corresponds to the width and height of the region's border rectangle, and not its content rectangle.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/ttml1/issues/221#issuecomment-266361443, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCb-QjtnIldd-1wHErrEYLqk2gCuicks5rHPmKgaJpZM4KwkdJ .

andreastai commented 7 years ago

OK. This is then information that needs to be reflected in a TTML 1 errata. I re-label this issue again as "bug" because I think that some information (at least in 9.3.3 Synchronic Flow Processing) needs correction.

In general to not re-use the semantics of XSL-FO and CSS seems not like a very good idea to me. But time for a discussion on this seems to have passed already.

skynavga commented 7 years ago

On Tue, Dec 13, 2016 at 10:42 AM, Andreas Tai notifications@github.com wrote:

OK. This is then information that needs to be reflected in a TTML 1 errata. I re-label this issue again as "bug" because I think that some information (at least in 9.3.3 Synchronic Flow Processing https://www.w3.org/TR/ttaf1-dfxp/#semantics-region-layout-step-2) needs correction.

In general to not re-use the semantics of XSL-FO and CSS seems not like a very good idea to me. But time for a discussion on this seems to have passed already.

I think it is not a case of the group having previously decided not to use XSL-FO or CSS, but rather, we didn't do a sufficient job specifying the mapping of extent to the allocation rectangle with which the region's extent boundary is coincident. Part of the fix will be to find a way to specify this in XSL-FO.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/ttml1/issues/221#issuecomment-266808120, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXCb76Nmt1bAFA8ku7FmZ9ymwm5XEuPks5rHtj5gaJpZM4KwkdJ .

andreastai commented 7 years ago

Part of the fix will be to find a way to specify this in XSL-FO.

Areas are created from XSL formatting objects (like boxes in CSS are created from elements). The generation of the "area tree" in XSL FO happens after refinement of the XSL FO formatting tree (where refinement includes amongst others computation of values and resolution of inheritance). As "rectangles" belong conceptually to the area tree generation it seems difficult to set width and height of them directly.

A feasible way from my perspective would be the following:

This would achieve what was intended and would be (as much as possible) aligned with concepts in XSL-FO and CSS.

nigelmegitt commented 7 years ago

[Meeting 2017-01-12] All agreed that the intended outcome is that padding is inset relative to the extent, so the extent of the region includes the padding and the border, and we need a solution that achieves that. @tairt volunteers to come up with a solution by the beginning of February.

nigelmegitt commented 7 years ago

When solution is available we should open an equivalent issue on ttml2.

nigelmegitt commented 7 years ago

mouse pointer slip just before hitting Comment, so clicked Close and comment by accident. Reopened.

skynavga commented 7 years ago

Please do not label this as a bug. The fact that we are looking at resolutions that involve only informative text is sufficient to demonstrate that point. A bug is a technical issue that requires a substantive change to fix.