Clarify application of padding (#221) #233
Conversation
andreastai
commented
Feb 5, 2017
andreastai
commented
- See Do tts:origin and tts:extent apply to the padded rectangle or the content rectangle? #221.
spec/ttml1.xml
Outdated
| @@ -5045,6 +5045,17 @@ then a presentation processor must use the closest supported value.</p> | |||
| the computed padding and the supported padding is minimized. If there are multiple closest supported values equally distant from | |||
| the computed value, then the value most distant from 0, i.e., the greatest padding, is used.</p> | |||
| </note> | |||
| <note role="elaboration"> | |||
| <p>Padding space is applied as inset space to the part of the region's area that corresponds to the large allocation rectangle | |||
| in <bibref ref="xsl11"/>. Because the extent of a TTML region defines the fixed dimensions of the large allocation rectangle, | |||
There was a problem hiding this comment.
This may be clearer to some readers if we change "Because" to "Since".
There was a problem hiding this comment.
Thanks for the review and the correction!
|
[Meeting 2017-03-09] agreed to apply the change requested by Nigel, then create as an errata and log the change. |
spec/ttml1.xml
Outdated
| To get the top left vertex of the content rectangle the values for padding-start and padding-before need to be added the region's | ||
| origin (subject to the value of the region's writingMode). | ||
| </p> | ||
| </note> |
There was a problem hiding this comment.
This note is overly detailed and long, and introduces conceptual dependencies on XSL-FO which we have generally avoided elsewhere (except for section 9.3.3). I am replacing this with two notes in this section (8.2.16), one that reiterates and emphasizes the previously supplied parenthetical "(or inset)", and another just after the example that elaborates the details of insetting while explicitly describing the extent of the remaining content rectangle. In addition, I am adding a note in section (8.2.7), the definition of tts:extent, that additionally notes that padding is interior to the region's extent.
There was a problem hiding this comment.
I think the key is to carefully define what region area means since there is no defined XSL equivalent. For instance, tts:overflow attribute defines whether a region area is clipped or not if the descendant areas of the region overflow its extent, but I assume that the clipping occurs outside the inset area, i.e. the area resulting from the region inset by padding, and not outside the region area.
spec/ttml1.xml
Outdated
| attributes that express a rectangle equivalent to the region's origin and | ||
| extent, and with a <att>line-stacking-strategy</att> attribute with value <code>line-height</code>;</p> | ||
| attributes that express a rectangle equivalent to the region's origin, | ||
| extent and padding, and with a <att>line-stacking-strategy</att> attribute with value <code>line-height</code>;</p> | ||
| </item> |
There was a problem hiding this comment.
Changing "and padding" to "(including padding)".
…nt, tts:padding; other minor edits. (#221)
|
Thanks @skynavga for proposing some further changes to the PR. I need some time to review the differences. |
|
@skynavga I'm puzzled - did you mean to close this pull request without merging it after editing the branch? |
|
Actually, I didn't knowingly close it. Rather, I was doing some branch
clean up last night and deleted the master branch (we are now using
gh-pages as master). Apparently, this PR was based on that master branch
(instead of gh-pages), and by deleting it, it closed the PR as a side
effect. I will create a new PR later today and populate it with the same
branch's content, i.e., issue-0221-clarify-padded-rectangle.
…On Mon, Apr 24, 2017 at 4:33 AM, Nigel Megitt ***@***.***> wrote:
@skynavga <https://github.com/skynavga> I'm puzzled - did you mean to
close this pull request without merging it after editing the branch?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb0ShGINrrr6wlk8miK7URA_f_130ks5rzHp-gaJpZM4L3f4R>
.
|
|
There's a better way - the PR can be edited to be based on a different source/destination branch rather than creating a new PR. |
|
I've changed the base branch as mentioned. |
|
ok, but next time, let me make the change so I will know how to do so in the future |
|
OK. For future reference, this was done by the following steps:
|
|
Thanks @nigelmegitt for your effort to keeping the info in the existing pull request! That makes tracking of the progress much easier. |
|
Can we merge this yet? Any further comments? |
|
No. As commented before I need to review the change to the PR. |
|
Are you requesting a full 14 day review?
…On Tue, Apr 25, 2017 at 12:40 AM, Andreas Tai ***@***.***> wrote:
No. As commented before I need to review the change to the PR.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb-CANsVRE0kQONRHTfvGNZKulmeXks5rzZVggaJpZM4L3f4R>
.
|
|
Yes, starting from 2017-04-20. |
|
ok, let us know if you finish your review earlier
…On Tue, Apr 25, 2017 at 1:41 AM, Andreas Tai ***@***.***> wrote:
Yes, starting from 2017-04-20.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb3778NwpddB-C7VSYbGmxC-csOwzks5rzaOlgaJpZM4L3f4R>
.
|
|
The edit made by @skynavga is actually a new edit and it shortens the semantics of the original PR considerably. The intent of the original PR was to clarify the relationship to XSL-FO and how TTML (in this case) "diverge" from the FO layout model. It was made more detailed here, because the implementer needs to understand fully what the difference is. The new edit leaves out this content (by intent). To say that padding is an inset space of the region area does not help because it is never said "what" area of the region is meant. The addition that the extent of the region includes the padding may be sufficient for some readers, but I prefer as stated a more detailed explanation. This should be reviewed also by others to decide which edit should be merged. |
|
On Tue, Apr 25, 2017 at 8:01 AM, Andreas Tai ***@***.***> wrote:
The edit made by @skynavga <https://github.com/skynavga> is actually a
new edit and the shortens the semantics of the original PR considerably.
Yes, and that is intentionally the case for a number of reasons.
(1) the original issue raised is whether origin/extent applies to the
padding rectangle or the content rectangle; the answer is that it applies
to neither, rather it applies to the an allocation rectangle of a
hypothetical area (region) inside of which is placed a padding rectangle,
and into which padding rectangle is placed a content rectangle; the edited
PR makes this answer abundantly clear;
(2) the original issue does not address what an implementation does or how
it does it in order to achieve the required results;
(3) your original PR text note only indirectly addressed (1) while focusing
on (2); indeed, it was difficult to ascertain (1) from your proposed note;
(4) it is not a goal for the TTML specifications to serve as implementation
guides; indeed, the target audience of TTML is content authors, both in
terms of what they must do to create conforming content, but also what they
may expect from conforming processors;
(5) TTML intentionally avoids going into details about possible
implementation approaches for a number of reasons: (a) it makes the
specification longer; (b) it can be or become overly prescriptive, and lead
to brittle implementations; (c) it can have negative affects on testing and
on acceptance criteria as a content specification;
The intent of the original PR was to clarify the relationship to XSL-FO
and how TTML (in this case) "diverge" from the FO layout model. It was made
more detailed here, because the implementer needs to understand fully what
the difference is.
While that may have been the intent of your original PR, that PR did not
address the core question of the issue, and unnecessarily introduces
irrelevant implementation detail, XSL-FO concepts, and, overall, is at odds
with the overall goals of TTML as a content specification. Furthermore, it
sets a dangerous precedent by potentially giving the impression that TTML
defines implementation behaviors, algorithms, etc.
The new edit leaves out this content (by intent).
Correct.
To say that padding is an inset space of the region area does not help
because it is never said "what" area of the region is meant. The addition
that the extent of the region includes the padding may be sufficient for
some readers, but I prefer as stated a more detailed explanation.
I don't know what reader would have difficulty in correctly interpreting
the intent especially given the new clarifying notes. Any reader, whether
content author or implementer, should have no trouble understanding what
extent applies to by making reference to the definitions under [1] combined
with knowledge that there is no margin and no border, which effectively
makes the allocation rectangle of the area generated by the block-container
to which region is mapped coterminous with the padding rectangle of that
same area.
[1] https://www.w3.org/TR/xsl/#area-geo
This should be reviewed also by others to decide which edit should be
merged.
Let me remind you. Editing the TTML specifications is not a public or group
activity. It is an editor's activity. The group members and others serve
merely as contributing authors when submitting a PR. There should be no
expectation that the exact text of a PR will be accepted by the editor.
It is the task of the editor to maintain thematic, conceptual, language,
and technical consistency in the specification. When there is disagreement
about how this is done, then for non-substantive editorial matters, the
editor is generally granted discretion. In the TTWG, this reflects the
editing process for the TTML series of documents.
When there is disagreement about substantive technical issues, then the WG
needs to find a consensus on the nature of the resolution, but that does
not translate into the editor accepting a word for word proposed resolution.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCbzD55yROdMuZdrZT8eHL_kTYucrFks5rzfzGgaJpZM4L3f4R>
.
|
It is a Group decision what to publish as a Working Draft (or later transition state document). If the Editor has taken a view for which there is no consensus in the Group then an edit will usually be needed to resolve that lack of consensus. So if the Editor chooses not to take Group input on-board then there should be no expectation that the Editor's Draft will be accepted by the Group and published. This tension is best avoided by working together to generate changes that everyone can live with. Here we have two differing views of the problem and the appropriate solution, and indeed the seriousness of that problem. I suggest we discuss this in our weekly call tomorrow. |
|
On Wed, Apr 26, 2017 at 8:16 AM, Nigel Megitt ***@***.***> wrote:
Let me remind you. Editing the TTML specifications is not a public or group
activity. It is an editor's activity. The group members and others serve
merely as contributing authors when submitting a PR. There should be no
expectation that the exact text of a PR will be accepted by the editor.
It is a Group decision what to publish as a Working Draft (or later
transition state document). If the Editor has taken a view for which there
is no consensus in the Group then an edit will usually be needed to resolve
that lack of consensus. So if the Editor chooses not to take Group input
on-board then there should be no expectation that the Editor's Draft will
be accepted by the Group and published. This tension is best avoided by
working together to generate changes that everyone can live with.
Here we have two differing views of the problem and the appropriate
solution, and indeed the seriousness of that problem. I suggest we discuss
this in our weekly call tomorrow.
It is useful to emphasize one point and add another to this thread:
(1) it has been a standing policy in TTML to minimize implementation
specific detail; this is based on a decision formed in the early work of
the WG, so my response to this thread has been to follow that decision
instead of questioning it;
(2) notwithstanding the above, I understand the interest in at least
discussing or even defining general or even specific approaches regarding
implementation matters; in this regard, there is no real home, formal or
informal, where such information can be documented; as such, this situation
could be improved by:
- creating a space where members, implementers, and other community
members could readily document implementation specific matters, including
questions, discussions, and recommendations; for example, we might create a
TTML specific wiki page covering this subject, and allow the community to
author or co-author its content;
- if sufficient quantity of implementation recommendations or guidelines
are documented and accepted over time, then they could be distilled into a
WG Note or other document that takes the form of an Implementation Guide or
Guidelines;
—
… You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCb_XIYEwDGNRueXmRCIWnLehGsy2Vks5rz1HQgaJpZM4L3f4R>
.
|
|
On Wed, Apr 26, 2017 at 11:54 PM, Pierre-Anthony Lemieux < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In spec/ttml1.xml
<#233 (comment)>:
> @@ -5045,6 +5045,17 @@ then a presentation processor must use the closest supported value.</p>
the computed padding and the supported padding is minimized. If there are multiple closest supported values equally distant from
the computed value, then the value most distant from 0, i.e., the greatest padding, is used.</p>
</note>
+<note role="elaboration">
+ <p>Padding space is applied as inset space to the part of the region's area that corresponds to the large allocation rectangle
+ in <bibref ref="xsl11"/>. Because the extent of a TTML region defines the fixed dimensions of the large allocation rectangle,
+ padding effectively reduces the available space for a content rectangle in the XSL-FO model.
+ This needs to be taken into account when the region's extent is conceptually mapped to dimensions of a content rectangle. For this
+ mapping the sum of the padding-before value and padding-after value and the sum of padding-start value and padding-end value need
+ to be subtracted from the region's width and height (subject to the value of the region's writingMode).
+ To get the top left vertex of the content rectangle the values for padding-start and padding-before need to be added the region's
+ origin (subject to the value of the region's writingMode).
+ </p>
+</note>
I think the key is to carefully define what *region area* means since
there is no defined XSL equivalent. For instance, tts:overflow attribute *defines
whether a region area is clipped or not if the descendant areas of the
region overflow its extent*, but I assume that the clipping occurs
outside the *inset area*, i.e. the area resulting from the region inset
by padding, and not outside the *region area*.
In this context, it means outside the region area.
… —
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#233 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAXCbxiAr8ziB_Kjzilu6B3-xI-gmc-1ks5r0C2pgaJpZM4L3f4R>
.
|
|
On Thu, Apr 27, 2017 at 1:34 AM, Glenn Adams ***@***.***> wrote:
On Wed, Apr 26, 2017 at 11:54 PM, Pierre-Anthony Lemieux <
***@***.***> wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In spec/ttml1.xml
> <#233 (comment)>:
>
> > @@ -5045,6 +5045,17 @@ then a presentation processor must use the closest supported value.</p>
> the computed padding and the supported padding is minimized. If there are multiple closest supported values equally distant from
> the computed value, then the value most distant from 0, i.e., the greatest padding, is used.</p>
> </note>
> +<note role="elaboration">
> + <p>Padding space is applied as inset space to the part of the region's area that corresponds to the large allocation rectangle
> + in <bibref ref="xsl11"/>. Because the extent of a TTML region defines the fixed dimensions of the large allocation rectangle,
> + padding effectively reduces the available space for a content rectangle in the XSL-FO model.
> + This needs to be taken into account when the region's extent is conceptually mapped to dimensions of a content rectangle. For this
> + mapping the sum of the padding-before value and padding-after value and the sum of padding-start value and padding-end value need
> + to be subtracted from the region's width and height (subject to the value of the region's writingMode).
> + To get the top left vertex of the content rectangle the values for padding-start and padding-before need to be added the region's
> + origin (subject to the value of the region's writingMode).
> + </p>
> +</note>
>
> I think the key is to carefully define what *region area* means since
> there is no defined XSL equivalent. For instance, tts:overflow attribute *defines
> whether a region area is clipped or not if the descendant areas of the
> region overflow its extent*, but I assume that the clipping occurs
> outside the *inset area*, i.e. the area resulting from the region inset
> by padding, and not outside the *region area*.
>
In this context, it means outside the region area.
Also, in TTML a tt:region maps to an fo:block-container, so the intent of
extent is to define the allocation rectangle that applies to the area
generated by the block container. And, since margins (space around) are
zero and since border thickness is zero (in TTML1), then that allocation
rectangle corresponds with the padding rectangle of the generated area. If
padding is also zero, then all of the extent is utilized as the content
rectangle for the generated area; otherwise, some (inset) is used as
padding and the content rectangle fits in the remaining available space.
For overflow scenarios, overflow would occur from the content that didn't
fit the content rectangle, and thus if overflow is visible, then would be
presented outside the content rectangle (into the padding sub-area(s) and
even potentially outside the region's extent.
It was left implementation dependent regarding whether such overflow
content would actually appear or would be clipped.
… —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#233 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAXCbxiAr8ziB_Kjzilu6B3-xI-gmc-1ks5r0C2pgaJpZM4L3f4R>
> .
>
|
TTML 1 styling and layout depends in most cases on XSL-FO as conceptual model. How padding is applied (or extent of the region is defined) diverge considerably from XSL-FO. This is the reason why more details have been given in the original PR. It is useful as background information to use XSL-FO as conceptual model despite this derivation. |
There was a problem hiding this comment.
This looks good to me in the sense that it clearly addresses the issue raised, and I doubt that anyone could remain in any doubt about the relationship between the region's extent, the padding and the content area.
I'm not sure it addresses use of the term "region area" but that should probably be a separate issue.
Yes. |
|
Note that the expression "region area" in TTML1 is not new, and is essentially a reference to the definition of "Region" found in the terminology section, i.e., "a rectangular area of a presentation surface". Adding a simple ", i.e., a region area," parenthetical in that term definition would suffice. |
