Apply improvements to aspect ratio and pixel semantics.

[palemieux]

This is an initial pass at rationalizing computation of aspect ratio and pixel dimensions.

Some highlights:

• IMHO the ultimate goal is to determine (a) the intended display aspect ratio of the root container, i.e. what the viewer sees, and (b) the meaning of px within the document coordinate system

• the mapping of the root container to the presentation viewport is left to profiles and/or applications, but can use the computed PAR, SAR, and DAR.

• the document coordinate system is specified as an abstract Cartesian coordinate system, i.e. independently of the notion of pixels.

I expect additional editorial will be needed, at the very least, but wanted to get the review started.

[palemieux]

diff at http://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fttml2%2Fspec%2Fttml2.html&doc2=https%3A%2F%2Fraw.githubusercontent.com%2Fw3c%2Fttml2%2Fa70a3078b018e5609fa470231182f40e8e06f3b5%2Fspec%2Fttml2.html

[skynavga]

I'm making an editing pass on this PR and will commit an update later this evening.

[skynavga]

Acronyms go into the Acronyms section.

[skynavga]

The purpose of terminology section is to provide some definition, and not just vector to a new location. So this edit is too radical.

[palemieux]

Ok.

[skynavga]

Ditto on acronyms.

[palemieux]

Wouldn't the terminology section be the right place to define acronyms?

[skynavga]

We have an acronyms section. I am creating an edit now to be posted later this evening.

[palemieux]

I missed the acronym section... so sounds good to move it there.

[skynavga]

Ditto on acronyms.

[skynavga]

This change is unnecessary and possibly overconstrained. In particular, the values of the numerator and denominator may be some other value than 1/1, e.g., 3/3 is equivalent. Reverting this change.

[skynavga]

Can't dispense with this language, am revising slightly to refer to root container region semantics appendix.

[skynavga]

Revising this change as it removes useful information, while adding nothing.

[skynavga]

Need to vector this definition to root container region semantics sub-section on coordinate space rather than attempt to define in this context. I will revise accordingly.

[skynavga]

Revering this removal, as this is useful information for reader.

[skynavga]

This is clearly wrong.

[palemieux]

What is wrong?

[skynavga]

If the coordinates of the lower right hand corner are <1,1>, then the entire coordinate space has only one pixel. Coordinates are in pixels, not percentages.

[skynavga]

I am close to committing an update on this branch, so please stand by for further changes.

[palemieux]

The point is that the coordinate system should not be in pixels since pixels are meaningless if tts:extent is not specified on tt.

[skynavga]

You may have forgotten that TTML always assumes the coordinate space is in pixels, and that a document can use px units even without specifying SAR, i.e., without specifying tts:extent on <tt>.

I note that IMSC and a few other profiles rule out this scenario, but it still applies to TTML as such.

[palemieux]

You may have forgotten that TTML always assumes the coordinate space is in pixels,

Without extent in px when dimensions are expressed in px, it is not possible to determine the relative dimensions of a region with (50%,50%) extent and one with (20px, 20px) extent.

This has been an issue with TTML1, and should be fixed in TTML2.

[skynavga]

Not really. In this case, the document processing context can choose a resolution, say, e.g., the resolution of a related media object, or in case of no media, an arbitrary resolution, e.g., "1000px 1000px". Having done so, it is straightforward to resolve both [50%,50%] and [20px,20px]. If the results are unexpected, then it is the authors fault for failing to specify a resolution in the first place. We can always add a strong warning against the use of pixels without specifying resolution, but for backwards interoperability, we can't change TTML1 retroactively. The bottom line is that processing behavior is well defined, even in the absence of sensible authorial input (on resolution).

[nigelmegitt]

I don't agree that TTML assumes the coordinate space is in pixels. It may well define semantics should an implementation make that assumption, but it also seems entirely possible (as well as a good idea in some cases) to author and present TTML documents without making references to logical TTML pixels anywhere. For example rw and rh units, or cell units, can be used throughout, and mapped to a vector image format on output that also only uses relative units.

[skynavga]

Resolution pending.

[skynavga]

I was expecting only that the existing specification text would be corrected if there was a substantive difference in technical understand of the desired results as we discussed in the London F2F. I did not expect a wholesale replacement of the existing text with a table that is not only difficult to interpret, but introduces a number of ambiguities, such has how to resolve over-constrained specified values. I am restoring the previous text and then editing it as needed to incorporate the results from the F2F in a manner I hope is consistent with the semantics of your replacement table.

[palemieux]

but introduces a number of ambiguities,

What ambiguities?

[skynavga]

See "such as ...".

[palemieux]

In absence of a specific example, tt sounds like you did not even try to read it.

[skynavga]

There you go again, accusing me of bad faith. Of course I read it. More than once. For example, your table says that PAR is DAR/SAR when both DAR and SAR are specified; however, if PAR is also specified, then this is ambiguous in the case that PAR is not DAR/SAR. Your table also appears to imply that tts:extent on <tt> may be lengths that use non-pixel units, but it is required to be in pixels if specified as lengths.

From TTML2 (10.2.16)

If a tts:extent attribute is specified on the tt element, then the specified value is restricted to one of the following: (1) the auto keyword, (2) the contain keyword, or (3) two <length> specifications, where these specifications are expressed as non-percentage, definite lengths using pixel units. All other syntactically legal values must not be used in this context, and, if used, must be considered an error for the purpose of validation processing and must be ignored for the purpose of presentation processing, in which case the initial value (auto) applies.

From TTML1 (8.2.7)

If tts:extent is specified on the tt element, then the width and height must be expressed in terms of two <length> specifications, and these specifications must be expressed as non-percentage, definite lengths using pixel units.

[palemieux]

however, if PAR is also specified, then this is ambiguous in the case that PAR is not DAR/SAR.

In London, we had decided that DAR/SAR would override the specified PAR value.

[palemieux]

Your table also appears to imply that tts:extent on <tt> may be lengths that use non-pixel units,

As it stands it can also be: 1) the auto keyword or 2) the contain keyword.

[skynavga]

I don't disagree that in that case PAR is overridden by DAR/SAR, but your table doesn't say that, and the reader may be confused. In any case, that was what I meant by ambiguity (as well as the non-pixel lengths on extent).

Yes, I agree that auto and contain are possible values, but your table didn't say that, so a reader might have thought that extent with a non-pixel length could apply.

[skynavga]

@palemieux edit applied to branch.

[skynavga]

Closes #30.

[skynavga]

@palemieux do you have any comments on the PR edits? what I'm looking for primarily is if you have any technical issues with the edits with respect to the table you proposed as a replacement, and, more specifically, whether you feel that my incorporation of the table's semantics into the earlier text is consistent with your mental model of resolving aspect ratios.

[palemieux]

@skynavga It is on my todo list.

[palemieux]

DAR acronym is already defined in the acronym section.

[palemieux]

Aspect ratio is already defined in the definition. No need to repeat it here.

[palemieux]

Why try to list all ways that aspect ratio can be computed when the following explains it in detail. This is likely to introduce inconsistencies and make the document more difficult to maintain.

[skynavga]

The two parts work in concert: the first part defines how specified values of aspect ratios are determined, the second part defines how resolved values of aspect ratios are determined. It is a two pass process, like determining specified and then computed values of style properties. If you believe there is a technical inconsistency, then please share that information.

[palemieux]

What are "storage or sample units"? Neither terms are used or defined anywhere else? Why is this relevant to the processing of the document?

[skynavga]

The term storage aspect ratio, as well as its synonyms or near-synonyms, frame aspect ratio, image aspect ratio, and picture aspect ratio, typically make referent to storage units and/or sample units, namely, the units of information that correspond to pixels in the context of a stored frame/image/picture. I suppose we could substitute "logical pixels" in this context, since they have the same intended meaning here.

[skynavga]

Replacing with logical pixels in pending fix.

[palemieux]

The means of determining DAR, SAR and PAR need to be in a single place and not sprinkled across the document, which makes reading it more complex and increases the chances of inconsistencies.

[skynavga]

Fix pending (by vectoring definitions in terminology section to Appendix H).

[palemieux]

What is the difference between the visual medium and the presentation viewport?

[skynavga]

The term visual medium is a term of art that goes back to CSS1 961217, where it is assumed and contrasted with non-visual media, expanded further in CSS2 980512 [2] as visual media group.

I am removing the term presentation viewport (and all other viewport related terms) since they are no longer referenced in the specification text.

[1] https://www.w3.org/TR/REC-CSS1-961217#appendix-e
[2] https://www.w3.org/TR/1998/REC-CSS2-19980512/media.html#media-groups

[palemieux]

The PAR cannot be the aspect ratio of the pixel on the presentation medium since these are completely out of the control of the author. The PAR can only be the aspect ratio of the logical pixel used by "px" measurements, right?

[skynavga]

Fix pending, by disconnecting display pixels from post-TTML processing.

[palemieux]

Where is the resolved resolution of the root container region determined? Is that in Section H.2?

[palemieux]

Appendix H does not use the term "spatial extent" once.

[skynavga]

Fix pending.

[palemieux]

This is application dependent and the DAR needs to be determined by the document processing context, even if a Related Media Object exists, which may not even be video.

[skynavga]

Fix pending.

[skynavga]

On Wed, May 24, 2017 at 9:56 AM, Nigel Megitt ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In spec/ttml2.xml <#321 (comment)>: > -<p>The coordinate space of the root container region, also known as the <loc href="#terms-document-coordinate-space">document coordinate space</loc>, -is an unbounded, two-dimensional plane on which a closed set of logical pixels are defined that take the form of a rectangle <emph>R</emph> such that -the said pixels are interior to (inside of) the <emph>R</emph>, and where the origin (position) of this coordinate space is coincident with the upper, -left-hand corner of <emph>R</emph>, and where positive pixels on the vertical axis extend downwards and positive pixels on the horizontal axis -extend rightwards. -Furthermore, the <loc href="#terms-width">width</loc> and <loc href="#terms-height">height</loc> of <emph>R</emph> is set to the -resolved resolution of the root container region. -Lastly, the aspect ratios that apply to <emph>R</emph> are established according to the resolved values of <code>DAR</code>, <code>SAR</code>, -and <code>PAR</code> as indicated above.</p> -<p>Unless a <loc href="#terms-higher-level-protocol">higher level protocol</loc> applies, -the <loc href="#terms-document-coordinate-space">document coordinate space</loc> is determined once and only once when processing a -given document instance.</p> +<p>The coordinate space of the root container region, also known as the <loc href="#terms-document-coordinate-space">document coordinate space</loc>, is a cartesian coordinate system with:</p> +<ulist> +<item><p>its origin coincident with the upper left-hand corner of the <loc href="#terms-root-container-region">root container region</loc>; and</p></item> +<item><p>the point with coordinates (1, 1) coincident with the lower right-hand corner of the <loc href="#terms-root-container-region">root container region</loc>.</p></item> I don't agree that TTML assumes the coordinate space is in pixels. It may well define semantics should an implementation make that assumption, but it also seems entirely possible (as well as a good idea in some cases) to author and present TTML documents without making references to logical TTML pixels anywhere. For example rw and rh units, or cell units, can be used throughout, and mapped to a vector image format on output that also only uses relative units.

The original authors of TTML have always assumed a pixel based coordinate system. From what I can tell, it is only with your recent arrival in the group and the focus on percentage based lengths in IMSC that you have arrived at a different position than is historically justified. In any case, I do agree with you that it is possible to construct a document without recourse to pixels, but that does not invalidate the existing assumption that the document coordinate space is in pixels, whether or not those pixels are referenced as such.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#321 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb5BybL0gtbfjqtMFu1INaVgSYnKEks5r9FMegaJpZM4Neg3C> .