Meeting minutes
This meeting
Nigel: Iterates through agenda. IMSC, WebVTT
Gary: No updates today on WebVTT
Nigel: Any other business, or points to get to?
Cyril: Question on IMSC 1.2, possibly a new feature. Can cover during IMSC or AOB
Nigel: Will cover at end of IMSC part.
group: [no other business]
IMSC Issues
Nigel: Most of the issues we're about to cover were raised by Glenn but he's not on the call right now.
… I think we should try to cover them anyway and see if there is a consensus amongst the rest of the group.
… This will hopefully allow us to make some progress.
Usage pattern for specifying an image's alternate text. imsc#490
github: https://github.com/w3c/imsc/issues/490
Nigel: This has been in IMSC since 1.1 hasn't it?
Pierre: Correct, and it follows the pattern for when smpte:backgroundImage is used, which is why we ended up here.
… Another data point is we should really refrain from making changes to image profile unless absolutely necessary.
… Maybe in the future there will be some new requirement for the image profile that will give us an opportunity to
… correct these things. At this point I don't think it would be worth the trouble and it would be particularly disruptive.
… I'm happy to close it or deschedule it and defer it to a backlog so we don't forget about it.
Nigel: That was going to be my suggestion.
Pierre: I propose moving to the backlog.
Nigel: Any other views on this? Any problems saying we may deal with it one day but not right now?
Pierre: An advantage of doing this is that if someone runs into this and starts raising an issue they should be able to
… find it in the open issues list fairly quickly, and comment on it.
Nigel: I'm hearing no objections - obviously Glenn is absent but he has the opportunity to comment during the review
… period as per our Decision Policy.
Resolution: We will not address this in IMSC 1.2 but leave on the backlog for potentially fixing in some future version.
tts:position should be permitted in image profile imsc#492
github: https://github.com/w3c/imsc/issues/492
Pierre: I think this falls into the same bucket as #490. It is important to note but not worth a substantive change.
Nigel: At this time?
Pierre: Yes.
Nigel: Any other views? The proposal is to not address in IMSC 1.2 but leave on the backlog.
group: [no objections]
Resolution: We will not address this in IMSC 1.2 but leave on the backlog for potentially fixing in some future version.
itts:forcedDisplay should apply to image element in image profile imsc#493
github: https://github.com/w3c/imsc/issues/493
Pierre: This is a direct parallel to #490. forced Display applies to div and not image.
… This is fine in Image profile because there's a 1:1 mapping between images and divs, so I suggest the same
… disposition, which is not to address in IMSC 1.2 but leave on the backlog.
Nigel: I took the step for this one of checking in with Glenn on the driver for the issue and it seems
… to be one of semantic asymmetry and inconsistency. I take the view also that this inconsistency is not great
… but is not enough of a motivation in itself to make a change at this time.
PROPOSAL: We will not address this in IMSC 1.2 but leave on the backlog for potentially fixing in some future version.
Nigel: Any objections?
group: [no objections]
Resolution: We will not address this in IMSC 1.2 but leave on the backlog for potentially fixing in some future version.
Potential semantic conflict between ttp:profile and ttp:contentProfiles. imsc#506
github: https://github.com/w3c/imsc/issues/506
Pierre: I think this is literally not an issue.
… I think it is not impossible to fulfil the IMSC document at the top of the issue with an empty document.
… It's a silly document but not impossible.
Cyril: When we have this situation with non-overlapping profiles, what should a validation processor do?
Pierre: TTML2 is very clear. Theoretically the validator knows about all the profiles being flagged.
… For instance processor profile is Image and document conformance is Text. A validator should flag the document
… as non conformant unless it is empty.
Cyril: but how? It will validate against the rules for Image or for Text and some might fail?
Pierre: The processor profile lists features the processor must support.
… In the thread there's a specific example.
… The processor profile is Image and the content profile is Text.
… That means the processor is only required to support those features supported by Image profile but the document
… must conform to Text profile.
… Let's say the document conforms to Text profile and is not empty, it contains some spans that are forbidden in Image Profile.
… A smart validator would recognise that, and see that a processor has no chance of processing that document
… accurately.
… It should flag it.
Andreas: But the document would still be conformant.
… The validator might warn but from the spec side it is not forbidden.
Pierre: That's correct.
Nigel: We should separate the two questions of a validator:
… 1. Is the document conformant to its declared content profile? (in this case, yes)
… 2. Would a processor that meets the requirements of the effective processor profile as computed from the document
… be able to process it successfully?
… The two questions are distinct.
Pierre: Andreas pointed out that from a validation standpoint the document would validate correctly because it does
… conform to Text profile. A smart validator might point out that the processor profile is only a subset and therefore
… it is unlikely that the document would be correctly rendered.
… That's my understanding of profiles in TTML2.
Cyril: It could also say the document is not valid for the processor profile.
Pierre: In TTML2 the way it is stated is if a feature is in a processor profile then the processor must support it but
… it does not say that the processor must not support other features.
… So the best thing a validator could say is a warning that on the requested type of processor the document might
… not present the document correctly.
Cyril: There's already a recommendation in the spec to use contentProfiles signalling unless backward compatibility
… with TTML1 is needed.
Pierre: [checks what it says]
… It already says either use Image or Text but not both. The only reasonable way to do both is an empty document.
… But yes IMSC says contentProfiles _should_ be present.
Cyril: We want to catch as much as possible at validation. I wonder how we can improve...
Pierre: It's a TTML2 issue that a TTML2 validator should flag this kind of stuff.
Nigel: We could say that if processor profiles is present and says one of Image or Text but not both and says
… the opposite of contentProfiles then that should generate a warning.
Pierre: We designed IMSC to be a superset of profiles like EBU-TT-D so I don't know how we'd write that.
Nigel: We would have to express it in terms of the computed set of features supported by the processor and enabled
… by the content profile. The set of features that may be present in the document should all be in the set of features
… supported by the processor, or generate a warning.
Pierre: That should be in the generic TTML2 validation processing not in IMSC though.
… Exactly what you suggested Nigel would be a good TTML2 addition. That's useful everywhere really.
Nigel: I can raise that as an issue then.
Pierre: One thing we could do is put that as a proposed resolution and move the issue into TTML2 instead of opening
… a new issue.
… See if Glenn has a reason why this is not a good idea.
Proposal: Add a normative SHOULD statement to TTML2: The set of features that may be present in the document should all be in the set of features supported by the processor, or generate a warning.
Nigel: I suggest we don't resolve this now but leave it open for Glenn to respond.
Pierre: That would be my preference.
SUMMARY: proposal listed above to add a normative SHOULD statement to TTML2, left open for further consideration before resolving.
Pierre: I'm reading what "validate a document" does and it does not do that at all at the moment today.
… I don't think this is covered in TTML2 today.
IMSC requirement query - lineShear
Cyril: We don't have lineShear in IMSC 1.1 because it is not implementable in CSS at the moment.
… Reminder: We have fontShear, lineShear and shear.
… lineShear applies to lines, shear to blocks, fontShear to glyphs.
… In IMSC 1.1 we only have shear.
… It is a problem for Netflix because we want the lineShear behaviour.
… The issue is that with multiple lines sheared then the second or third lines are shifted up or down for vertical lines.
… That is not the desired rendering so we are forced to break a multi-line paragraph into multiple
… single line paragraphs. That is painful but there are side effects for ruby position and boutens.
… We rely on the outside value of textEmphasis position.
… With two back to back paragraphs with single lines then it doesn't behave as expected because
… the position acts on lines within the paragraph not outside.
… It's more of a burden to author.
… My question is how would the group feel about adding lineShear in IMSC 1.2
Pierre: I think that summary is correct.
… The challenge with adding it to IMSC 1.2 is the same as existed before.
… Until it is supported by browsers, it's going to be hard to get enough implementations.
Cyril: I understand that. I would suggest adding it to the WD and discussing with the CSS WG and maybe put the
… feature at risk and if we can't implement then remove it.
Pierre: We did that in IMSC 1.1 so we can do it again here.
… We have to convince the browser people. They don't support shear at all.
Cyril: Yes, you can do it with transforms.
Pierre: Yes, the problem is doing transform per line because you can't tell what a line is, then you have to wrap
… a line into a display:block etc. A polyfill is a lot of work but probably possible.
Cyril: I'm reopening it. I'm not hearing any objection.
Pierre: That's a good idea, and I don't have a strong objection to putting it in as at risk just like with IMSC 1.1.
Nigel: Does the new CSS writing modes Rec say anything about this?
Cyril: No, nothing to do with shear.
Pierre: Some folk from the CSS WG and JLReq group from the print industry don't think shear should ever be used, so
… we have to overcome that I think.
… [apologies I have to drop off in a moment]
… I don't object to raising this with the browser community.
… There are errata to cover at some point; we can do that next time?
Nigel: Sure.
Pierre: To go over the errata next meeting.
Nigel: Anything more on this topic?
AOB: (Re-)join to timed text WG after charter renewal
Nigel: Atsushi sent an email around. Quick poll: has anyone had any issues rejoining?
Cyril: No but I'm confused. I asked my AC rep to join Netflix again, and that happened. Do I have to do something
… individually.
Nigel: It's hard to tell. I had the same issue. Atsushi was able to check for me.
Cyril: I'll send him an email.
Nigel: Any other queries about this?
group: [no other queries]
Use of TTML in ATSC and timestamps
Cyril: I've had discussions with multiple people that in ATSC with DASH it is not very clear how,
… in TTML in MP4 files, what the time values inside the TTML documents should be.
… Should they be relative to the ISOBMFF file in which they're carried, or the DASH period or something else?
… It seems that some people have been using UTC timestamps. I wanted to know the group's opinion.
Nigel: I've looked at this in some detail.
… I think Cyril, you, me and Romain published something a few years ago!
… BBC does publish DASH MPDs where the track timeline begins on 1 Jan 1970.
… The TTML times within any single sample ISO BMFF need to fall into that sample's period on the timeline
… otherwise the content won't be presented by a client - it will be temporally clipped.
… This is clear.
… Then it is a separate decision for e.g. ATSC if they think it is useful to specify some common track timeline across
… all services. They can do that but from a client perspective if all they are doing is receiving a DASH MPD and playing
… the content then it doesn't matter what that timeline is, as long as the TTML payload content has appropriate times
… within it.
TTML in MP4 and MPEG-DASH guidelines
Cyril: Ok, thank you - it would be worth reminding ATSC about this I think.
Meeting close
Nigel: Thanks everyone, we've completed our agenda for today. Next week's meeting will be the final call of 2019.
… [adjourns meeting]