Re: Examples of Per-Profile IMSC Specific Presentation Processing by a MPIP

Thanks Glenn,

This helps answer one of my questions from yesterday's meeting.

It is tempting to cautiously suggest that we could define the behaviour for a presentation processor, be it a single profile or multiple profile IMSC processor, that causes it to exhibit the desired behaviour regardless of which profile the document actually conforms to, making the decision process moot in that case.

In other words:
* processors that support IMSC-I (IPIP) will always successfully process conforming IMSC-I documents
* processors that support IMSC-T (TPIP) will always successfully process conforming IMSC-T documents
* processors that support both IMSC-I and IMSC-T (MPIP) will always successfully process conforming IMSC-I documents and conforming IMSC-T documents without needing to know which they are in advance of processing

I'm not sure how long the list will end up being, but for the examples you've provided here are some potential rules that would hopefully allow implementations to behave desirably, i.e. to make every effort to present content in the intended way, inline below:

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Thursday, 7 January 2016 19:19
Since folks have wondered what type of semantic processing may need to discriminate on which profile applies, I have collected a small set of examples that apply to presentation processing without any consideration of verification/validation. At least one implementation (TTPE) implements code to handle these cases:

  *   nested tt:div
     *   IMSC-T supports nested div, while IMSC-I does not; an MPIP needs to respect nesting for the former, but ignore (or collapse divs) or abort for the latter;

An MPIP or IPIP encountering a div with an image attribute and one or more descendant child div, p, span or br elements shall process the image attribute and may ignore the div's content and child elements.
An MPIP or IPIP encountering a div D with an image attribute where D has a parent div element may ignore D.

  *   tts:displayAlign
     *   IMSC-T supports all values, while IMSC-I prohibits its use; so an MPIP would need to use displayAlign when processing the former, but ignore or abort for the latter;

An MPIP or IPIP may ignore any specified value of displayAlign when presenting images.

(in this case I don't think the value of displayAlign has any impact anyway since the image is required to be equal in size to the region)


  *   tts:padding
     *   IMSC-T supports padding on region, while IMSC-I does not; an MPIP needs to respect the former, and ignore (or abort) the latter

An MPIP or IPIP encountering an image attribute on a div whose applicable region has a non-zero tts:padding style attribute on any edge shall ignore the padding when presenting the image.

  *   tts:writingMode
     *   IMSC-T supports all values, while IMSC-I prohibits vertical modes; so an an MPIP would need to enable all modes for the former, but ignore or abort if vertical mode is used with the latter;

An MPIP or IPIP encountering an image attribute on a div whose applicable region has a vertical writing mode (as enumerated by the #writingMode-vertical feature in TTML1) shall present the image without rotation or reflection.

> MPIP = Multiple-Profile IMSC Processor
IPIP = Image Profile IMSC Processor
TPIP = Text Profile IMSC Processor

Might this be a helpful approach? Reasons I can think of why it might not be helpful are:
1) it could invalidate existing implementations
2) the list may be so long that we cannot complete this exercise sensibly

In many cases the only scenario I can construct where an MPIP might have to worry about these rules is one where it is processing a non-conformant document instance, i.e. one that would  be rejected by validating processors for either profile. Perhaps we would be able to limit the list to scenarios that could reasonably be encountered by valid documents.

Thoughts welcome, positive or negative.

(I need more time to look at the proposed text in the other related email – I just got to this one first)

Nigel




----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------