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