Property tts:origin permits rw/rh but #origin is defined per TTML1.

[palemieux]

Define an additional feature that specifies processing of rw/rh lengths on tts:origin

[nigelmegitt]

I'm not actually sure we need this. There is a feature gap in which <length> admits rw and rh syntactically, but the #origin features is based on the TTML1 definition that does not allow those units. The actual impact of that gap seems small. I'm assuming we have other theoretical feature gaps if we look hard enough, but that we've taken the view that they don't necessarily need to be filled.

Another resolution would be to prohibit use of rw and rh on tts:origin.

[skynavga]

Technically, such a feature definition is not needed, the reason being is that the feature #length-root-container-relative is intended to operate as a mix-in feature, just like, e.g., #length-em #length-cell, etc., with all properties that employ a <length> expression, such as tts:outline.

I suggest closing this issue with no further action.

[palemieux]

Ok with me.

[skynavga]

Closing this per #972 (comment).

[nigelmegitt]

@palemieux #972 (comment) seems to imply that if, in IMSC 1.1, we permit #origin and #length-root-container-relative, then the correct interpretation is that tts:origin values using rw or rh units need to be supported. I don't think this mix-in model is well described or clear, and I think we actually don't want that behaviour in IMSC1.1. So maybe a clarification action in IMSC1.1.