Add missing @extent attribute to isd:isd.

[skynavga]

Both ttp:displayAspectRatio and ttp:pixelAspectRatio are defined for use on isd:isd; however, an extent attribute was neglected to be defined (but is already implemented and used in TTX/TTPE). In order to support the use of rw and rh units in ISDs, as well as complete the triangle for (SAR/DAR/PAR), we need to define an extent attribute to take two pixel based length expressions for use on isd:isd.

[nigelmegitt]

Surely a pixel extent is absolutely not required to process rw and rh units? That's the point of them.

[nigelmegitt]

I've no objection to permitting extent on isd, but I would have if we were to require it. The associated pull request is safe in that respect, since it does not require it.

[skynavga]

Merged early per WG resolution to move forward with CR3 CfC.

[css-meeting-bot]

The Working Group just discussed Add missing @extent attribute to isd:isd. ttml2#919, and agreed to the following:

• SUMMARY: Discussion about dimension resolution in ISDs and condition evaluation, no changes needed to the spec resulting from this discussion.

The full IRC log of that discussion

<nigel> Topic: Add missing @extent attribute to isd:isd. ttml2#919
<nigel> github: https://github.com//issues/919
<nigel> Glenn: This issue was to define the extent attribute for use on the isd syntax, which at
<nigel> .. this point I consider to be new and that it will be refined over time. So I have avoided
<nigel> .. going too far down the path of defining constraints on usage here.
<nigel> .. The problem here was that in appendix H of TTML2 we compute all of the aspect ratios
<nigel> .. , the resolution of the root container region and the document coordinate space for
<nigel> .. the extent of the root container region. In H.2 the resolution computes a resolution in
<nigel> .. logical pixels near the beginning of processing, at least before any time you need to
<nigel> .. make use of width or height of root container region, and it stays that way during processing.
<nigel> .. If the author does not specify a tts:extent on the root container element then the
<nigel> .. implementation puts in a value that it wants to use, for example the SAR of a related
<nigel> .. media object, etc. So it always comes up with a number in logical pixels to use there.
<nigel> .. That means when other measurements are expressed in the ISD after going through
<nigel> .. the process of using computed style values those might be expressed in pixels and
<nigel> .. be encoded as pixels as opposed to rw or rh. They might have started out as rw or rh
<nigel> .. but the implementation might have expressed them as pixels. We have made no
<nigel> .. assumptions about the units in the ISD. It may be disadvantageous to do early
<nigel> .. translation to pixels, for example em, c units etc might be in the ISD. In the absence
<nigel> .. of an extent attribute that records what the implementation chose, then it becomes
<nigel> .. difficult to resolve them, or it would be done by the receiving end.
<nigel> .. Nigel you commented that surely a pixel extent is not required to compute rw or rh.
<nigel> .. That depends on what you're using them for. Maybe, or maybe not. I wanted to comment
<nigel> .. on your question there.
<nigel> q+
<nigel> ack n
<nigel> Nigel: Thanks for that, I don't disagree, and I think that a lot depends on the processing
<nigel> .. model. Either way requiring extent on isd:isd would be wrong in general, even though
<nigel> .. in some processing contexts it would be needed, so constrained by the implementation.
<nigel> .. Indeed one approach might be to resolve dimensions into canonical units and generate
<nigel> .. another ISD document based on an input ISD document, for example.
<nigel> Glenn: I just want to make sure we're on the same page.
<nigel> Nigel: I think we are.
<nigel> Glenn: I wanted to mention that the condition attribute may also show up in the ISD
<nigel> .. for example, consider a case when you can only resolve a condition at presentation time,
<nigel> .. or it is used at layout time and some parameter changes from when the ISD was generated.
<nigel> .. In those cases you might have condition show up in the ISD and whatever processes the
<nigel> .. ISD might have to do further processing on it.
<nigel> Nigel: That raises the question of if resolution of condition expressions can change the
<nigel> .. set of ISDs that can be generated?
<nigel> Glenn: Sure, they absolutely can. I think there's a note that evaluation of a condition
<nigel> .. might change results, and in that case the condition needs to be propagated to the next
<nigel> .. processing stage, or something to that effect. In other words, early resolution of
<nigel> .. conditions depends on the application and the semantics of the condition expression.
<nigel> .. For example the parameter based system allows environment defined parameters that
<nigel> .. are undefined.
<nigel> s/undefined/implementation-dependent
<nigel> Nigel: Right, so if an implementation cannot resolve a parameter at ISD formation stage
<nigel> .. then it needs to propagate that condition downstream until something can resolve it.
<nigel> Glenn: Right.
<nigel> Pierre: My conclusion is it is really not possible to evaluate rw and rh until there is a known
<nigel> .. aspect ratio and I've not heard anyone disagreeing with that.
<nigel> Nigel: Yes
<nigel> Glenn: I would amend that to say a known resolution - the aspect ratios are an input to
<nigel> .. the resolution and the resolution is what is needed to compute rw and rh units, as
<nigel> .. computed in appendix H.2.
<nigel> Glenn: I also put in a note near the end of our CfC editing, in one of the other issues,
<nigel> .. that reminds users that logical pixels do not have a defined shape or size until they
<nigel> .. are mapped to display pixels, and I've done a better job of defining inline terms that
<nigel> .. define logical pixel and display pixel and referring to them elsewhere using links. Hopefully
<nigel> .. that will help readers.
<nigel> SUMMARY: Discussion about dimension resolution in ISDs and condition evaluation, no changes needed to the spec resulting from this discussion.