IRC log of tt on 2019-09-18
Timestamps are in UTC.
- 23:47:26 [RRSAgent]
- RRSAgent has joined #tt
- 23:47:26 [RRSAgent]
- logging to https://www.w3.org/2019/09/18-tt-irc
- 23:47:28 [trackbot]
- RRSAgent, make logs public
- 23:47:28 [Zakim]
- Zakim has joined #tt
- 23:47:30 [trackbot]
- Meeting: Timed Text Working Group Teleconference
- 23:47:30 [trackbot]
- Date: 18 September 2019
- 23:47:33 [nigel]
- rrsagent, this meeting spans midnight
- 23:53:14 [cyril]
- cyril has joined #tt
- 23:56:22 [atsushi]
- atsushi has joined #tt
- 23:59:20 [pal]
- pal has joined #tt
- 00:01:33 [cyril]
- scribe: cyril
- 00:01:37 [cyril]
- present+
- 00:01:38 [nigel]
- Present+ Nigel_Megitt
- 00:01:44 [nigel]
- Chair: Nigel
- 00:01:55 [cyril]
- nigel: 2 days of meeting
- 00:02:03 [cyril]
- ... a lot of different topics to cover
- 00:02:07 [atsushi]
- present+
- 00:02:12 [nigel]
- -> https://www.w3.org/wiki/TimedText/tpac2019#Agenda_and_Schedule Agenda
- 00:02:14 [nigel]
- Agenda: https://www.w3.org/wiki/TimedText/tpac2019#Agenda_and_Schedule
- 00:02:15 [atai]
- atai has joined #tt
- 00:02:32 [cyril]
- ... we have a bunch of documents that we want to progress
- 00:02:41 [cyril]
- ... and we haven't begun horizontal review
- 00:02:54 [cyril]
- ... a goal is to decide which documents should get to WD to trigger HR
- 00:03:08 [cyril]
- ... the new process requires 3 months between WD and CR
- 00:03:24 [cyril]
- ... second goal is deciding what to do with TTML3
- 00:03:28 [cyril]
- ... 3rd WebVTT
- 00:03:37 [cyril]
- ... and 4th MIME types for embedded media
- 00:04:09 [cyril]
- pal: I'd like to resolved on the font file size issue
- 00:04:31 [cyril]
- nigel: we have several TTML2 topics
- 00:04:36 [atsushi_]
- atsushi_ has joined #tt
- 00:05:38 [cyril]
- ... I listed CSS properties but I don't know when we will discuss it
- 00:05:56 [cyril]
- ... for Danmaku, we will meet the Chinese IG tomorrow
- 00:07:46 [gkatsev]
- present+
- 00:08:22 [cyril]
- ... the schedule is arranged to cover for people departure times
- 00:09:20 [cyril]
- atai: we probably need 45 min for 360
- 00:10:22 [cyril]
- atai: we could have a short slot for demoing
- 00:10:33 [cyril]
- ... I would be interested in giving a 5-10min demo
- 00:11:40 [cyril]
- nigel: the schedule does not include anything about charter
- 00:11:46 [cyril]
- ... the WBS survey is closed
- 00:11:59 [cyril]
- ... do you know if anybody is planning to explain to us about the charter?
- 00:12:42 [cyril]
- atsushi: I have no information from PLH
- 00:18:15 [cyril]
- nigel: [tweaking the agenda]
- 00:19:32 [cyril]
- Topic: M&E IG follow-up
- 00:20:02 [cyril]
- atai: we could also have followups of the break out sessions to prepare for the next meeting
- 00:20:28 [gkatsev]
- -> https://www.w3.org/2019/09/16-me-minutes.html#item11 M&E IG joint meeting minutes
- 00:20:33 [inamori_]
- inamori_ has joined #tt
- 00:20:35 [cyril]
- cyril: how many topics were adressed ?
- 00:20:42 [cyril]
- atai: most of the time we discussed 360?
- 00:20:46 [cyril]
- s/?//
- 00:21:07 [cyril]
- pal: my take away is that there was no extension to support for text in MSE
- 00:21:40 [cyril]
- s/extension/objection/
- 00:21:52 [cyril]
- ... no objection, some support but this needs implementation
- 00:22:29 [nigel]
- cyril: Some details to sort out, main problem is native parsing support, TextTrackCue v2
- 00:22:40 [nigel]
- .. Want to discuss MSE, DataCue and v2 TextTrackCue.
- 00:22:42 [nigel]
- .. Mental model:
- 00:23:04 [nigel]
- .. DataCue is the API used to surface events or information contained inband e.g. in an MP4 file
- 00:23:18 [nigel]
- .. The major use case is emsg box and metadata in general, not subtitles
- 00:23:26 [nigel]
- i/cyril:/scribe: nigel
- 00:23:31 [nigel]
- .. DataCue is how you surface thing
- 00:23:46 [nigel]
- .. TextTrackCue v2 is how you pass information in the other direction.
- 00:23:53 [nigel]
- .. DataCue flows browser -> app
- 00:24:03 [nigel]
- .. TextTrackCue flows app -> browser
- 00:24:29 [nigel]
- Glenn: The native platform could be parsing the inband subtitling then surfacing it as a TextTrackCue if it wanted to.
- 00:24:49 [nigel]
- .. The immediate use case is to allow the script to do the parsing by getting data from DataCue or something like that.
- 00:25:08 [nigel]
- .. Somehow you need to get the data into the javascript to construct the data model to populate the TextTrackCue which
- 00:25:11 [nigel]
- .. can then be presented.
- 00:25:18 [nigel]
- Cyril: Continuing model.
- 00:25:36 [nigel]
- .. The content of the text track does not flow into the app.
- 00:25:44 [nigel]
- .. MSE controls the synchronisation and what text track is used and so on.
- 00:25:54 [nigel]
- .. The added value is management of buffering and synchronisation more properly.
- 00:26:07 [nigel]
- Pierre: It has more opportunity to do sync more accurately.
- 00:26:28 [nigel]
- Cyril: Because little browser support for TTML, how can you have MSE support for Text Tracks without native support.
- 00:26:48 [nigel]
- .. Wondering if MSE calls the app to do the parsing in Javascript and the result is a TextTrackCue object passed to
- 00:26:55 [nigel]
- .. MSE that handles buffering, pre-rendering and synchronisation.
- 00:27:09 [cyril]
- scribe: cyril
- 00:27:23 [cyril]
- pal: unless it's encrypted, applications can do the extraction
- 00:27:32 [cyril]
- ... why do ask browsers to do parsing?
- 00:27:38 [cyril]
- ... just do it yourself
- 00:28:01 [cyril]
- nigel: that's based on the model that the raw data that MSE exposes could be an IMSC document
- 00:30:10 [cyril]
- ... for example unwrapping mp4 containe
- 00:31:49 [cyril]
- cyril: MSE could do the unwrapping, pass the IMSC/WebVTT doc to the app, the app would create an object and pass it back to MSE
- 00:32:05 [cyril]
- nigel: what about accessibility?
- 00:32:20 [cyril]
- ... the BBC player always puts the right attributes on the div that displays the subtitles
- 00:32:31 [cyril]
- ... so that an assistive technology would read this out
- 00:32:39 [cyril]
- ... we would do adhoc repositioning when controls appear
- 00:33:01 [atsushi]
- i/cyril: Some details to sort out,/scribe: nigel/
- 00:33:05 [cyril]
- ... I'm trying to think whether any of these proposals would have impact
- 00:33:34 [atsushi]
- rrsagent, please make log public
- 00:33:57 [cyril]
- gkatsev: you can also change the size of the div
- 00:34:06 [atsushi]
- rrsagent, please make log public
- 00:34:08 [cyril]
- nigel: that's not enough to deconflict the UI from the text
- 00:34:13 [atsushi]
- rrsagent, please draft public
- 00:34:13 [RRSAgent]
- I'm logging. I don't understand 'please draft public', atsushi. Try /msg RRSAgent help
- 00:34:20 [atsushi]
- rrsagent, please draft minutes
- 00:34:20 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html atsushi
- 00:34:44 [cyril]
- nigel: I'm concerned that if you pass it down you don't have controls
- 00:35:23 [cyril]
- cyril: on the other hand, if you pass it to the browser, it can handle PiP, fullscreen, second screen
- 00:35:24 [inamori_]
- inamori_ has joined #tt
- 00:35:41 [cyril]
- gkatsev: people who use captions would not want screen readers over captions
- 00:35:56 [cyril]
- nigel: not everybody who can't hear can't see
- 00:36:04 [cyril]
- pal: what can this group do?
- 00:36:06 [nigel]
- s/can't see/can see
- 00:36:16 [cyril]
- ... that's a media WG discussion
- 00:36:58 [cyril]
- atai: to understand Cyril's model, is the rendering of the cue done by the browser?
- 00:37:01 [cyril]
- cyril: yes
- 00:37:37 [cyril]
- atai: this whole makes sense with the improvment about integrated rendering
- 00:38:00 [cyril]
- nigel: the 2 problems seem to have some symmetry
- 00:38:12 [cyril]
- ... why audio/video are not treated as subtitles?
- 00:38:24 [cyril]
- pal: if you encrypt subtitles, then there is an issue
- 00:38:42 [cyril]
- ... you'd have to discuss how to expose it back or not to the app
- 00:39:10 [cyril]
- cyril: I've never heard of encrypted subs
- 00:39:33 [cyril]
- nigel: the synchronization seems difficult in the browsers
- 00:39:44 [cyril]
- ... the DataCue breakout was interesting
- 00:39:58 [cyril]
- ... foolip said you misread the time marches on algorithm in the HTML spec
- 00:40:26 [cyril]
- gkatsev: the timeupdate event firing is limited
- 00:40:33 [cyril]
- nigel: I think that spec needs to be updated
- 00:40:51 [cyril]
- ... he's view is that the intent was that the time marches on should be run more frequently
- 00:41:23 [cyril]
- ... and a good implementation should be able to trigger the onenter/onexit close to the actual time
- 00:41:53 [cyril]
- ... Chris Cunningham assigned a Chrome bug to himself
- 00:42:55 [cyril]
- ... if you give it to MSE you may have more accurate timing but if the cue events are fired at a better time
- 00:43:10 [cyril]
- gkatsev: I think there is benefit to having that
- 00:43:29 [cyril]
- ... but maybe less of an advantage once the time marches on thing is fixed
- 00:44:05 [nigel]
- scribe: nigel
- 00:44:25 [nigel]
- Cyril: Relying on cue event timing isn't going to be as good as relying on native.
- 00:44:44 [nigel]
- .. Implementation is really painful at the moment relying on maintaining synchronisation with timeupdate events etc
- 00:45:12 [nigel]
- gkatsev: In video.js we use timeupdate but we're thinking of adopting RequestAnimationFrame
- 00:45:14 [cyril]
- scribe: cyril
- 00:45:27 [cyril]
- gkatsev: it's been working fairly well so far
- 00:46:15 [cyril]
- nigel: have we got any request for the Media WG?
- 00:46:27 [cyril]
- gkatsev: we can talk about that with them
- 00:46:44 [cyril]
- ... they are all tied together?
- 00:46:56 [cyril]
- cyril: is it a good idea to present my model?
- 00:47:02 [cyril]
- gkatsev: yes
- 00:47:20 [cyril]
- pal: we could discuss separation of work between WICG, TTWG and Media WG
- 00:47:34 [cyril]
- ... if it deals with Timed Text format and accessibility
- 00:47:57 [cyril]
- ... if it is an API question it's the WICG or Media WG
- 00:48:18 [cyril]
- ... that means that if they see a need to extend the formats or accessbility aspects, they should come back to us
- 00:48:52 [cyril]
- ... in this group, we will not have sufficient browser vendors representation
- 00:49:00 [cyril]
- ... and vice versa
- 00:49:31 [cyril]
- atai: the WICG is the place where the 2 communities would meet
- 00:50:27 [cyril]
- nigel: the WICG allows people to develop micro features without process
- 00:51:27 [cyril]
- atai: any activity yet on the WICG?
- 00:51:38 [cyril]
- pal: Tess took the action item to get that started
- 00:52:16 [cyril]
- cyril: this will be on discourse?
- 00:52:19 [cyril]
- pal: yes
- 00:52:43 [cyril]
- gkatsev: should we discuss that with the Media WG tomorrow?
- 00:52:50 [cyril]
- cyril: yes, I can draft some slides
- 00:53:02 [gkatsev]
- -> https://discourse.wicg.io/ WICG discourse
- 00:53:02 [cyril]
- Topic: CSS WG meeting follow-up
- 00:53:11 [cyril]
- nigel: that was a good meeting, very constructive
- 00:53:29 [cyril]
- ... it went better that previous meetings
- 00:53:39 [cyril]
- ... there was good progress on all of the issues
- 00:53:54 [cyril]
- ... the specs will be updated
- 00:54:11 [cyril]
- ... but their feedback was that either we should implement the proposed changes
- 00:54:17 [cyril]
- ... or ask someone to do it
- 00:54:22 [cyril]
- gkatsev: we could add tests
- 00:54:50 [cyril]
- nigel: well it was not mentionned
- 00:55:27 [cyril]
- gkatsev: adding tests is good because browser vendors do pay attention to failures in WPT
- 00:55:52 [cyril]
- glenn: what features?
- 00:56:06 [cyril]
- nigel: line alignment (multiRowAlign) and line padding
- 00:56:29 [cyril]
- pal: if somebody cared enough, PR against Chromium or Firefox
- 00:56:33 [cyril]
- ... would help
- 00:56:42 [cyril]
- ... they care about doing good rendering
- 00:58:12 [cyril]
- nigel: that's where we are with the CSS WG and we should be happy about that
- 01:00:10 [nigel]
- -> https://github.com/w3c/csswg-drafts/issues/4319 CSS Issue 4319
- 01:00:43 [cyril]
- atsushi: this was discussed in JLTF
- 01:01:09 [cyril]
- ... it was mentioned that it may have conflicts with boutens
- 01:01:46 [cyril]
- pal: we could say that text emphasis is not allowed on upright text
- 01:02:00 [cyril]
- glenn: they showed examples of prints that had that
- 01:02:21 [cyril]
- ... put the emphasis on the tate chu yoko block
- 01:06:20 [cyril]
- atsushi: there is a new property that allows specifying a limit to the number of characters in Tate Chu Yoko
- 01:07:11 [cyril]
- pal: where should the discussion happen?
- 01:07:27 [cyril]
- atsushi: from an HTML and CSS point of view, you should not use TCY for long text
- 01:10:25 [cyril]
- pal: I'm told that in DCinema 4digits years are displayed upright
- 01:12:33 [cyril]
- cyril: Netflix's style guide says do not use combine for more than 2 characters
- 01:18:09 [nigel]
- -> https://github.com/w3c/jlreq/issues/109 JLREQ issue 109
- 01:20:32 [nigel]
- -> https://github.com/w3c/i18n-activity/issues/726 i18n issue 726
- 01:23:47 [nigel]
- Topic: break until 1045
- 01:49:31 [atsushi]
- https://github.com/w3c/charter-timed-text/issues
- 01:52:35 [glenn]
- glenn has joined #tt
- 01:52:35 [atai]
- Topic: IMSC 1.1 issues
- 01:52:37 [nigel]
- scribe: atai
- 01:53:12 [nigel]
- Topic: forcedDisplay and visibility="hidden" imsc#484
- 01:53:18 [nigel]
- github: https://github.com/w3c/imsc/issues/484
- 01:53:55 [atai]
- Nigel: This was discussed in CSS WG and with APA
- 01:54:28 [atai]
- ...there is a view that CSS speech spec is tended for this kind of purpose
- 01:55:33 [gkatsev]
- -> https://www.w3.org/TR/css3-speech/#speaking-props-speak speak css property
- 01:55:35 [atai]
- ...erika from CSS WG Commented if you set visibility to hidden but speak property ? it is supposed to be sent to the screen reader
- 01:56:02 [atai]
- ...it was not clear from me from the spec that it should behave that way
- 01:56:12 [atai]
- gkatsev: spec is ambiguous
- 01:56:29 [atai]
- Nigel: I now think there is something needed
- 01:56:29 [cyril]
- cyril has joined #tt
- 01:57:02 [atai]
- ...CSS WG had volunteers to look at it
- 01:57:25 [atai]
- gkatsev: Currently this is defined in CSS3 speech
- 01:57:45 [atai]
- nigel: It is a buggy spec
- 01:58:07 [cyril]
- rrsagent, pointer
- 01:58:07 [RRSAgent]
- See https://www.w3.org/2019/09/18-tt-irc#T01-58-07
- 01:58:24 [cyril]
- rrsagent, draft minutes
- 01:58:24 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html cyril
- 01:58:25 [atai]
- ...values for speak property are possibly wrong
- 01:58:59 [atai]
- gkatsev: The alway value is confusing and needs update
- 01:59:25 [atai]
- nigel: they may have thought of the difference between visibility and display but it is not clear
- 02:00:02 [atai]
- ...action: we need to wait for the result of the a11y task force
- 02:00:13 [atai]
- ...after we have an outcome we can see what to do next
- 02:00:44 [atai]
- glenn: in ttml we ended up merging the properties
- 02:01:07 [atai]
- ...we have values like normal, fast
- 02:01:22 [atai]
- Nigel: There is a difference in CSS:
- 02:01:48 [atai]
- ...if you use speech representation that is how it should be styled
- 02:02:07 [atai]
- glenn: I thought auto is display none
- 02:02:51 [atai]
- Nigel: The idea in for CSS speak that you can direct screen reader for audio representation even if they
- 02:03:02 [atai]
- ...do not have a pixel representation
- 02:03:46 [atai]
- ...I now see that is a retired note in annotation in the spec
- 02:04:33 [atai]
- Summary: Wait what the CSS a11y TF come up with
- 02:05:25 [nigel]
- Topic: Support `#font` TTML2 feature #imsc472
- 02:05:41 [glenn]
- s/merging the properties/merging voice-rate semantics into tta:speak/
- 02:05:44 [nigel]
- github: https://github.com/w3c/imsc/issues/472
- 02:06:20 [ericc]
- ericc has joined #tt
- 02:06:33 [atai]
- Nigel: It is about font feature in IMSC 1.1
- 02:06:40 [glenn]
- s/I thought auto is display none/.../
- 02:06:46 [atai]
- ...Pierre question is about ressource limit
- 02:07:29 [atai]
- pal: questions:
- 02:07:35 [atai]
- ...should processors support a minimum set of font formats
- 02:07:45 [atai]
- ....should @type be limited to a certain set of values?
- 02:07:52 [atai]
- ...should the number of resources be limited in a document?
- 02:07:58 [atai]
- ...should the size (in bytes) of each resource be limited?
- 02:08:10 [atai]
- ...regarding should @type be limited to a certain set of values?
- 02:09:04 [atai]
- ...my recommendation is to not require to constraint @type but the browsers need to support a minimum list of font ressources
- 02:09:35 [atai]
- ...for the start of the spec the limit for the number of ressources my proposal is 2
- 02:09:46 [atai]
- Nigel: Why should we limit?
- 02:09:54 [atai]
- pal: Download time
- 02:10:25 [atai]
- cyril: we could make a difference between the number of ressources in the document
- 02:10:36 [atai]
- ...and the number that should be loaded at begin time
- 02:11:09 [atai]
- pal: do we have a strategy of effective font loading in ttml
- 02:11:49 [atai]
- glenn: we have a strategy and named it
- 02:11:59 [atai]
- ...lazy loading in our discussion
- 02:12:12 [atai]
- ...it is an implemenation dependent feature
- 02:12:47 [atai]
- Nigel: Number of number font elements can be restricted
- 02:13:48 [atai]
- ...you expect each one font element just one font ressource to be loaded
- 02:14:18 [atai]
- ...if you want to restrict it you should restrict number of font element
- 02:16:02 [atai]
- glenn: I would not like to constraint neither font element nor ressources
- 02:16:35 [atai]
- ...the application can decide on the basis the referenced font information what to fetch
- 02:17:23 [atai]
- pal: if you use fetch mechanism you can make the limitation bytes
- 02:17:48 [atai]
- ...the downside of fetch it requires full processing of the document
- 02:18:08 [atai]
- ...full processing like styke resolution etc.
- 02:18:35 [atai]
- glenn: This is a constraint you can only test during presentation processing
- 02:18:45 [atai]
- glenn: coult it be a constraint in the HRM
- 02:18:49 [atai]
- pal: yes
- 02:19:14 [atai]
- ...as info: digital cinema sets fetch limit to 10 MB
- 02:19:28 [atai]
- ...spoke with adobe colleague
- 02:19:42 [atai]
- ...this is no coincidence
- 02:20:02 [atai]
- ...it just works there
- 02:20:38 [atai]
- atsushi: In Japan we provide only a subset of a font
- 02:20:46 [atai]
- ...this limits the size
- 02:21:07 [atai]
- cyril: I don't think that we at netflix we would do font subsetting
- 02:21:08 [Zakim]
- Zakim has left #tt
- 02:21:30 [atai]
- ...especially for the first episode you have to provide all
- 02:21:49 [Zakim]
- Zakim has joined #tt
- 02:22:36 [atai]
- glenn: noto sans font 8.6 mb for simplfied chinese
- 02:23:04 [atai]
- gkatsev: We can start with 10 MB and then see if anybody is complaining
- 02:23:17 [atai]
- ...in that case we increase the limit
- 02:24:08 [atai]
- Pal: everybody agrees to have 10 MB as limit
- 02:25:05 [nigel]
- PROPOSAL: For FPWD limit fetched font resource to 10 megabytes
- 02:25:12 [nigel]
- Nigel: Any objections?
- 02:25:22 [nigel]
- RESOLUTION: For FPWD limit fetched font resource to 10 megabytes
- 02:25:39 [atai]
- pal: Constraint on @type
- 02:25:48 [atai]
- ...my suggestion no constraint
- 02:26:39 [atai]
- ...but require IMSC to support minimum set of font formats
- 02:27:32 [atai]
- PROPOSAL: no constraint on @type but IMSC processors need to support minimum set of font formats
- 02:27:52 [atai]
- RESOLUTION: No constraint on @type but IMSC processors need to support minimum set of font formats
- 02:28:05 [atai]
- pal: But...which font format?
- 02:28:07 [nigel]
- i/RESOLUTION: Nigel: Any objections?
- 02:28:14 [atai]
- ...we need to be careful
- 02:28:19 [nigel]
- i/RESOLUTION: /Nigel: Any objections?
- 02:28:26 [nigel]
- s|i/RESOLUTION: Nigel: Any objections?||
- 02:28:31 [atai]
- ...there are couple of formats woff woff2...
- 02:28:38 [nigel]
- i/RESOLUTION/group: [no objections]
- 02:28:54 [atai]
- ...I have not the expertise to decide what is hard not hard
- 02:30:12 [atai]
- cyril: We need one compressed and one uncompressed format
- 02:30:30 [atai]
- Nigel: There is an example in the DVB spec
- 02:30:31 [cyril]
- https://caniuse.com/#search=woff
- 02:30:43 [glenn]
- OTF's SVG table defined at https://docs.microsoft.com/en-us/typography/opentype/spec/svg
- 02:32:24 [atai]
- ...font download it supports OFF (Open font format) and WOFF
- 02:32:34 [atai]
- ...that is where I would start
- 02:32:42 [atai]
- cyril: we can discuss about woff2
- 02:32:50 [atai]
- ...it is broadly supported
- 02:33:24 [atai]
- ...and compresses better
- 02:33:28 [nigel]
- andreas: It would be good to get a view from Vladimir Levantovsky from Monotype who is a member of this group too.
- 02:34:04 [atai]
- pal: we wanted to specify requirement of processorts
- 02:34:54 [atai]
- s/processorts/processors/
- 02:36:18 [atai]
- cyril: we should constraint it to not support svg-outline
- 02:37:05 [nigel]
- PROPOSAL: Require minimally processor support for font/otf with cff and ttf (i.e. no svg outline) plus woff
- 02:37:20 [atai]
- Nigel: Any objections?
- 02:38:08 [atai]
- RESOULTION: Require minimally processor support for font/otf with cff and ttf (i.e. no svg outline) plus woff
- 02:38:24 [nigel]
- s/RESOULTION/RESOLUTION
- 02:38:54 [atai]
- gkatsev: woff2 has 30% better compression (as a data point)
- 02:40:30 [atai]
- cyril: about unicode range
- 02:41:26 [atai]
- ...I am satisfied with the current solution in Pierres PR
- 02:42:08 [atai]
- nigel: I have an example with two fonts and different sources
- 02:42:14 [atai]
- ...but overlapping sources
- 02:42:23 [atai]
- ...should we constraint this?
- 02:42:34 [atai]
- ...is there a use case for this?
- 02:42:54 [atai]
- glenn: Usually we leave it to the implementation what make sense
- 02:43:40 [atai]
- pal: In this case we constraint the size of fetch ressource
- 02:44:03 [atai]
- ...are we asking the implementation to find out the minimum set need
- 02:44:08 [atai]
- ...seems complicated
- 02:45:43 [atai]
- glenn: we have font slelection strategy in in TTML2
- 02:46:00 [atai]
- nigel: this is orthogonal to this discussion
- 02:46:40 [atai]
- pal: what we can do
- 02:47:01 [atai]
- ...we can forbid different fonts with the same font family
- 02:47:46 [atai]
- nigel: we may have different fonts and ressources for the same font family because they are for different faces
- 02:48:01 [atai]
- ...e.g. bold, italics ...
- 02:48:50 [atai]
- Nigel: we can try to constraint font family together with different properties like weight
- 02:49:35 [atai]
- pal: how do unicode range goes together with fetch
- 02:50:27 [atai]
- ...it needs to be validated by the processor when the size is exceeded
- 02:50:48 [atai]
- ...the typical usecase is one font and one font family, right?
- 02:51:42 [atai]
- Nigel:
- 02:52:21 [atai]
- atai: NPO in Netherlands have the requirement to have two fonts in one document (one for Arabic and one for Dutch version of the subtitle)
- 02:52:59 [atai]
- pal: even if you have two fonts it make sense
- 02:53:34 [atai]
- ...to constraint the combination for ranges, family, stylee and weight
- 02:54:05 [atai]
- s/stylee/style/
- 02:55:51 [atai]
- Nigel: I see two propsoals
- 02:57:36 [atai]
- ...you forbid to have unicode range overlab between different font elements with the same values for font famliy, style and weight
- 02:57:45 [atai]
- ...or to have no constraint
- 02:58:31 [atai]
- glenn: There may have identical font elements with different kerning tables
- 02:58:46 [atai]
- pal: you can forbid that
- 02:59:25 [glenn]
- https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#font-style-matching
- 03:00:43 [atai]
- glenn: I would recommend that implementation follow the algorithm defined by css
- 03:01:47 [atai]
- the HRM should use this algorithm
- 03:01:56 [atai]
- pal: this would solve that issue
- 03:02:40 [atai]
- glenn: ttv does some (not all) HRM checking
- 03:02:48 [ericc]
- ericc has joined #tt
- 03:03:17 [atai]
- nigel: You can not specifiy the HRM constraint
- 03:03:55 [atai]
- ...you can not statically validate this as font resssouces may change dynamically
- 03:04:54 [atai]
- pal: idea of hrm is to provide basic guidlines so things are going to work
- 03:08:57 [glenn]
- see https://www.w3.org/TR/2018/REC-css-fonts-3-20180920/#composite-fonts for text on handling overlapping ranges
- 03:09:47 [atsushi]
- s/overlab/overlap/
- 03:09:51 [atai]
- PROPOSAL: Unicode range overlab between different font elements are permitted even they have identical values for style, family and weight
- 03:10:10 [atai]
- Nigel: Any objection?
- 03:10:13 [atai]
- No objections
- 03:10:43 [atai]
- Resolution: Unicode range overlap between different font elements are permitted even they have identical values for style, family and weight
- 03:11:14 [atai]
- TOPIC: IMSC 1.1 FPWD
- 03:11:16 [atsushi]
- s/overlab/overlap/
- 03:11:35 [atsushi]
- rrsagent, please draft minutes
- 03:11:35 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html atsushi
- 03:12:55 [atai]
- Proposal: Once we merged the open PR we go to PPWD
- 03:13:01 [atai]
- Nigel: Any objections?
- 03:13:03 [nigel]
- s/PPWD/FPWD
- 03:13:05 [atai]
- No objections
- 03:13:24 [atai]
- Resolution: Once we merged the open PR we go to FPWD
- 03:13:39 [atai]
- s/PPWD/FPWD/
- 03:13:47 [nigel]
- s/IMSC 1.1/IMSC 1.2
- 03:20:00 [nigel]
- Topic: Lunch
- 04:02:46 [atai]
- atai has joined #tt
- 04:03:37 [atsushi]
- atsushi has joined #tt
- 04:05:16 [gkatsev]
- Topic: Live Extensions
- 04:05:40 [nigel]
- scribe: gkatsev
- 04:06:00 [gkatsev]
- nigel: [pulls up repo]
- 04:06:11 [gkatsev]
- nigel: there's a few things we need to cover
- 04:06:26 [gkatsev]
- ... last time we talked about it pal asked for some offical communication from EBU
- 04:06:30 [gkatsev]
- ... they had already done so
- 04:06:37 [gkatsev]
- ... in the reflector
- 04:07:05 [gkatsev]
- ... I've taken on the role of editor
- 04:07:21 [cyril]
- cyril has joined #tt
- 04:07:22 [pal]
- pal has joined #tt
- 04:07:32 [gkatsev]
- ... three docs
- 04:07:38 [gkatsev]
- ... 1. one is normative part
- 04:07:44 [gkatsev]
- ... 2. live carriage
- 04:07:50 [gkatsev]
- ... 3. live extensions guide
- 04:07:58 [gkatsev]
- ... take first two to req and 3rd one as a note
- 04:08:03 [glenn]
- glenn has joined #tt
- 04:08:36 [cyril]
- rrsagent, pointer
- 04:08:36 [RRSAgent]
- See https://www.w3.org/2019/09/18-tt-irc#T04-08-36
- 04:08:42 [gkatsev]
- ... atsushi: how do you do PR preview in repos with respect to make it easier to review
- 04:08:54 [gkatsev]
- atsushi: there is a tool for preview
- 04:09:07 [gkatsev]
- nigel: how to make it work with multiple docs in the same repo?
- 04:09:14 [inamori_]
- inamori_ has joined #tt
- 04:09:39 [gkatsev]
- ... maybe pr-preview can be configured
- 04:09:44 [gkatsev]
- ... can you look into it, atsushi?
- 04:09:47 [gkatsev]
- atsushi: yes
- 04:10:07 [gkatsev]
- nigel: currently no PRs or issues against it, only editorial notes
- 04:10:25 [gkatsev]
- ... as a reminder, the scope is for contribution of live streamed subs to distribution encoder
- 04:10:40 [gkatsev]
- ... the idea is not that these extensions would apply to a wide number of users
- 04:10:57 [gkatsev]
- ... if you've got an IMSC distribution encoder with a live distribution mechanism such as HLS or DASH
- 04:11:04 [gkatsev]
- ... this provides a way to get the content to that
- 04:11:19 [gkatsev]
- ... approach taken is to define some extension features
- 04:11:25 [gkatsev]
- ... key things are:
- 04:11:42 [gkatsev]
- ... introduces concept of a sequence with an identifier and number
- 04:11:49 [gkatsev]
- ... to resolve temporal issues
- 04:12:01 [gkatsev]
- ... tt-live is the main specification
- 04:12:10 [gkatsev]
- ... has anyone reviewed it?
- 04:12:22 [gkatsev]
- atai: yes
- 04:12:26 [gkatsev]
- others: no
- 04:12:39 [gkatsev]
- atai: I have comments on the basic structure
- 04:12:53 [gkatsev]
- nigel: let me continue briefly and hear it late
- 04:12:57 [gkatsev]
- s/late/later/
- 04:13:06 [gkatsev]
- nigel: describes temporal overlap resolution mechanism
- 04:13:21 [gkatsev]
- ... defines processing semantics which are important for usecases in the scnearios of live
- 04:13:32 [gkatsev]
- ... the ability to delay delivery of documents or time within documents
- 04:13:35 [gkatsev]
- ... handling reference clocks
- 04:13:44 [gkatsev]
- ... the ability to hand over between subtitlers
- 04:14:00 [ericc]
- ericc has joined #tt
- 04:14:13 [gkatsev]
- ... typicly in a live authoring one person will be subtitling and when they're done they hand it over to another subtitler
- 04:14:27 [gkatsev]
- ... this doc describes how to resolve inputs coming from multiple sources
- 04:15:13 [nigel]
- -> https://w3c.github.io/tt-module-live/tt-live-1/spec/tt-live.html TTML Live Extensions Module
- 04:15:19 [gkatsev]
- ... new constraints attributes on time base, sequenceIdentifier, sequenceNumber, authorsGroupIdentifier, authorsGroupControlToken, referenceClockIdentifier
- 04:15:46 [gkatsev]
- cyril: what's the difference between stream and sequence
- 04:15:58 [gkatsev]
- nigel: sequence set of documents with the same identifier
- 04:16:07 [gkatsev]
- ... and a stream is is the delivery of that sequence between two endpoints
- 04:16:08 [atsushi]
- s/respect/respec/
- 04:16:59 [glenn]
- q+
- 04:17:00 [gkatsev]
- ... i've defined a profile which is simple
- 04:17:25 [gkatsev]
- ... a little bit from imsc, I've found I've needed as well as the concepts of permitted and prohibited, I needed optional and required
- 04:17:34 [gkatsev]
- ... the profile describes some extension features
- 04:18:02 [gkatsev]
- ... Apendix has requirements for carriage specifications
- 04:18:08 [gkatsev]
- atai: thank you for you work
- 04:18:27 [gkatsev]
- ... I know there has been several years of discussion to get to this state and several edits
- 04:18:38 [gkatsev]
- ... I know what's in there is all necessary input to solve the problem
- 04:18:51 [gkatsev]
- ... but I also would really like to get this adopted by the market
- 04:19:00 [gkatsev]
- ... the market needs less coplexity
- 04:19:30 [gkatsev]
- ... at the end what the core scenario is the sequence number and everything else is for handler
- 04:19:43 [gkatsev]
- ... to solce the core problem we possibly just need the timing model and the sequence number
- 04:19:51 [gkatsev]
- ... that would be easier to digest for a lot of people
- 04:20:01 [gkatsev]
- nigel: so, separate out things like hand off?
- 04:20:11 [gkatsev]
- atai: system model is important but not relevant to everyone
- 04:20:21 [gkatsev]
- ... main usecase is contribution of live subtitles to a streaming encoder
- 04:20:32 [gkatsev]
- ... out of band live captions to the encoder and get delivered via DASH or HLS
- 04:20:40 [gkatsev]
- ... so, less is more
- 04:20:43 [gkatsev]
- nigel: thank you
- 04:21:06 [gkatsev]
- glenn: so you're suggesting this is paired down to core normative pieces
- 04:21:50 [gkatsev]
- glenn: another option is to move all the normative syntactic pieces to the top and move everything to appendixes to the meat of it is at the top
- 04:22:10 [gkatsev]
- ... issue if the top section references the system model it could be confusing
- 04:22:21 [gkatsev]
- nigel: section 6 is the meat of it
- 04:22:26 [gkatsev]
- glenn: I thought sectio 10 was
- 04:22:31 [gkatsev]
- s/sectio/section/
- 04:22:37 [gkatsev]
- cyril: annex B is also important
- 04:23:02 [gkatsev]
- cyril: PDF of tt-live is 44 pages
- 04:23:05 [gkatsev]
- nigel: incredible
- 04:23:13 [gkatsev]
- ack glenn
- 04:23:32 [gkatsev]
- glenn: under the namespaces section, it was vague whether you were redefining or defining or merely copying from TTML 1
- 04:23:42 [gkatsev]
- ... in general, I don't like copying normative defs if possible
- 04:23:53 [gkatsev]
- ... I see you've changed the prefix to tt:tt
- 04:23:58 [gkatsev]
- nigel: might be a bug
- 04:24:17 [gkatsev]
- glenn: having a copy of the normative defs across docs has some challenges, FYI
- 04:24:25 [gkatsev]
- nigel: I understand concern, not sure I agree
- 04:24:37 [gkatsev]
- ... if I were defining the namespace, it would be a problem. just saying shall be used
- 04:24:50 [gkatsev]
- glenn: I would put a note that the namespace is defined in TTML and link to it
- 04:25:09 [gkatsev]
- nigel: I think this is done by reference, but we can adjust it to make more clear
- 04:25:14 [gkatsev]
- ... it isn't claiming to redefine anything
- 04:25:23 [gkatsev]
- ... new vocabulary are below
- 04:25:26 [gkatsev]
- glenn: xml schema isn't used
- 04:25:35 [gkatsev]
- nigel: maybe another bug
- 04:25:48 [gkatsev]
- nigel: xs:string is used
- 04:25:58 [gkatsev]
- glenn: make a note to say that normative defnitions are found in the appropriate docs
- 04:26:07 [gkatsev]
- nigel: please raise an issue, it would be good
- 04:26:27 [gkatsev]
- glenn: the items that have both optional and permitted in the profile section have some overlap
- 04:26:31 [gkatsev]
- ... it's a bit unclear
- 04:27:06 [gkatsev]
- ... both optional or permitted in live handover
- 04:27:19 [gkatsev]
- nigel: live handover is optional and permitted if it's a handover manager node
- 04:27:30 [gkatsev]
- glenn: it wasn't clear to me
- 04:27:56 [gkatsev]
- cyril: maybe make it clearer by saying optional for everything or permitted by handover manager node
- 04:28:06 [gkatsev]
- glenn: just having OR in there would've alleviated my concerns
- 04:28:18 [gkatsev]
- nigel: anything else?
- 04:28:30 [gkatsev]
- pal: I will review and suggest anything further
- 04:28:41 [gkatsev]
- atai: it isn't about the technical quality
- 04:28:49 [gkatsev]
- ... it's about experience on how people look at long documents
- 04:28:59 [gkatsev]
- ... I think to get the core scenario working, you don't need too much
- 04:29:09 [gkatsev]
- nigel: I'm definitely to hear suggestions on refactoring the document
- 04:29:22 [nigel]
- s/to hear/happy to hear
- 04:29:36 [gkatsev]
- glenn: I noticed you used SHALL, does IMSC use MUST? We use MUST everwhere
- 04:29:56 [gkatsev]
- atai: this is a followup from EBU joined meeting in geneva
- 04:30:01 [gkatsev]
- ... one idea was also to align with IMSC
- 04:30:11 [gkatsev]
- nigel: the way that this is structured is that it's an extension
- 04:30:18 [gkatsev]
- ... previously extension to EBU-TT
- 04:30:22 [gkatsev]
- ... nothing specific to EBU-TT
- 04:30:36 [gkatsev]
- ... by moving here by defining extensions means we can apply to IMSC as well
- 04:30:47 [gkatsev]
- ... so we can have an IMSC live that supports both this profile and IMSC itself
- 04:30:53 [gkatsev]
- ... that would provide a path towards live IMSC
- 04:31:02 [gkatsev]
- ... that's a design goal
- 04:31:13 [gkatsev]
- glenn: a couple other editorial comments
- 04:31:23 [gkatsev]
- ... I would suggest editing extensions to extension, at the top
- 04:31:38 [gkatsev]
- ... instead of v1, I would suggest just using 1 to match TTML1
- 04:31:56 [gkatsev]
- ... I've been calling other modules timed-text instead of tt
- 04:32:06 [gkatsev]
- ... not tie directly to TTML so IMSC can also use it
- 04:32:13 [gkatsev]
- ... we should pick a qualifier and use it for all modules
- 04:32:19 [gkatsev]
- ... I don't have a huge preference
- 04:32:31 [gkatsev]
- nigel: any ore on this one of the 3 docs?
- 04:32:44 [gkatsev]
- glenn: are you read to publish as a working draft?
- 04:32:59 [gkatsev]
- nigel: this has not been published, it's effectively an editor's draft
- 04:33:14 [gkatsev]
- pal: to me criteria is whether normative section portions match source EBU doc
- 04:33:18 [gkatsev]
- nigel: they do
- 04:33:21 [gkatsev]
- pal: then publish
- 04:33:26 [gkatsev]
- ... just publish today
- 04:33:32 [gkatsev]
- nigel: and refactor can happen after
- 04:33:43 [nigel]
- -> https://w3c.github.io/tt-module-live/tt-live-1/spec/carriage/WebSocket/tt-live-carriage-WebSocket.html WebSocket Carriage Mechanism
- 04:33:53 [gkatsev]
- ... next one is carriage mechanism
- 04:34:09 [gkatsev]
- ... one of the features of the main doc is a carriage mechanism
- 04:34:17 [gkatsev]
- ... this specifies how to do it over web socket
- 04:34:22 [gkatsev]
- cyril: 14 pages
- 04:34:30 [gkatsev]
- nigel: unbelievable
- 04:34:41 [gkatsev]
- glenn: can we get a sense on whether tt or timed-text
- 04:34:55 [ericc]
- ericc has joined #tt
- 04:35:22 [gkatsev]
- nigel: wanted a brand name that's easy to say: TTML Live
- 04:35:29 [gkatsev]
- ... felt as shortest brand name
- 04:35:48 [gkatsev]
- glenn: should I go and changed Timed Text to TTML? In say Karaoke
- 04:35:57 [gkatsev]
- ... Timed Text Karaoke or TTML Karaoke?
- 04:36:02 [gkatsev]
- cyril: one question
- 04:36:16 [gkatsev]
- ... what is the conformance to this document
- 04:36:35 [gkatsev]
- ... is it a node or encoder? how do you verify comformance?
- 04:36:37 [gkatsev]
- glenn: how do you test it?
- 04:36:55 [gkatsev]
- nigel: definitions optional required etc translate to a pair of document requires
- 04:37:01 [gkatsev]
- ... and processor conformance requirements
- 04:37:26 [gkatsev]
- ... those permutations are defined by the profile disposition in section 6
- 04:37:35 [gkatsev]
- cyril: have you thought about CR exit criteria for this?
- 04:37:45 [gkatsev]
- nigel: well, they are implementation criteria, so, there should be tests for those
- 04:37:52 [gkatsev]
- ... from my perspective, I know 3 implementations
- 04:37:57 [gkatsev]
- ... one open source lead by me
- 04:38:03 [gkatsev]
- ... one is closed source by red beam
- 04:38:10 [gkatsev]
- ... another is closed source by FAB
- 04:38:17 [gkatsev]
- ... closed source can generate docs
- 04:38:30 [gkatsev]
- ... open source and consume and generate docs and output IMSC
- 04:38:44 [gkatsev]
- ... we can certainly contribute back some of the validty tests from the open source
- 04:39:08 [gkatsev]
- nigel: so the web socket carriage mechanism, it's pretty straight forward
- 04:39:32 [gkatsev]
- ... just iterate thoguh each of the considerations from the main document for carriage and let the web socket do the heavy lifting
- 04:39:48 [gkatsev]
- ... there are certain rules about connection lifecycle and error management that relate to the websocket RFC
- 04:39:58 [gkatsev]
- ... there are some normative provisions that match what ws requires
- 04:40:06 [gkatsev]
- ... any comments on that one?
- 04:40:22 [gkatsev]
- cyril: so to demonstrate intertop, you'd need a websocket server?
- 04:40:42 [gkatsev]
- nigel: yes, you would have the normative provisions that if you send an invalid document it would break the connection
- 04:40:49 [gkatsev]
- cyril: so it's more of a protocol?
- 04:40:57 [gkatsev]
- nigel: yes, it's a good question how to test this
- 04:41:04 [nigel]
- -> https://w3c.github.io/tt-module-live/tt-live-1/guide/tt-live-guide.html TTML Live Guide
- 04:41:11 [gkatsev]
- ... let's move to the guide
- 04:41:33 [gkatsev]
- ... some may remember that EBU-TT has a lot of discussion and informative text that I've moved to this guide
- 04:41:46 [gkatsev]
- ... some duplication from the main doc but it's all informative
- 04:41:55 [gkatsev]
- ... there are things like time graphs showing results of processing
- 04:42:06 [gkatsev]
- ... how overlaps get resolved
- 04:42:14 [gkatsev]
- ... lots of details that hopefully will help
- 04:42:32 [gkatsev]
- ... some of the things atai asked for examples with copmuted and resolved times
- 04:42:41 [gkatsev]
- ... there's an editorial note to bring to this document
- 04:43:02 [gkatsev]
- ... all of this needs no comformance language but just explanatory text
- 04:43:17 [gkatsev]
- ... all sections say "This section is non-normative"
- 04:43:25 [gkatsev]
- ... any questions on this?
- 04:43:47 [gkatsev]
- ... in response to pal's point earlier, move the first two docs on the req track to move to FPWD
- 04:44:04 [gkatsev]
- ... I'll create PRs based on glenn's issues
- 04:44:18 [gkatsev]
- ... should we go straight to FPWD or have another review period?
- 04:44:25 [gkatsev]
- ... no requirement for quality to go to FPWD?
- 04:44:35 [gkatsev]
- ... this is implemented already
- 04:44:47 [gkatsev]
- cyril: we don't have much expertise on this in the group
- 04:44:52 [gkatsev]
- ... would be nice to have a wide review
- 04:45:02 [gkatsev]
- atai: there's a certain amount of people who looked within EBU
- 04:45:19 [gkatsev]
- ... so it's really important to get peer review on this, it should generally be understandable
- 04:45:33 [gkatsev]
- ... specific live scenarions, conditions, etc
- 04:45:42 [gkatsev]
- ... most complicated is the timing model
- 04:45:55 [gkatsev]
- glenn: I second motion to FPWD
- 04:46:23 [gkatsev]
- PROPOSAL: go to FPWD for the Live extension module and the carriage mechanism after resolving current open issues
- 04:46:29 [gkatsev]
- nigel: any objections?
- 04:46:40 [gkatsev]
- nigel: no objections
- 04:46:49 [gkatsev]
- RESOLUTION: go to FPWD for the Live extension module and the carriage mechanism after resolving current open issues
- 04:47:09 [gkatsev]
- nigel: one other thing to bring to attention that may not be obvious
- 04:47:31 [nigel]
- -> https://github.com/w3c/tt-module-live/blob/master/tt-live-1/design/live-to-rtp.md Relationship to TTML in RTP
- 04:47:45 [gkatsev]
- ... there is an IETF document about embedding TTML in RTP
- 04:47:58 [gkatsev]
- ... could be seen as a way to do live
- 04:48:12 [atsushi_]
- atsushi_ has joined #tt
- 04:48:25 [gkatsev]
- ... wrote a doc about creating a TT-Live from a TTML doc in RTP and vice versa
- 04:48:33 [gkatsev]
- ... there's some interesting complexity
- 04:48:45 [gkatsev]
- ... tt-live is done from prespective that's all info is in the doc
- 04:48:53 [gkatsev]
- ... in RTP some of the info is in the wrapper
- 04:49:52 [gkatsev]
- glenn: you used TT-Live
- 04:49:58 [gkatsev]
- nigel: I should change it to be consistent
- 04:50:21 [gkatsev]
- gkatsev: using Timed Text may confuse someone thinking it could apply to WebVTT, when it may not
- 04:50:28 [gkatsev]
- cyril: should we talk wot WebRTC WG?
- 04:50:37 [gkatsev]
- nigel: they have a req to make live captioning in WebRTC
- 04:50:47 [gkatsev]
- atai: there are people doing live captioning in webrtc
- 04:50:59 [gkatsev]
- glenn: some people were talking about this in the M&EIG
- 04:51:12 [gkatsev]
- ... was quite involved in RTC and proposed some subtitles
- 04:51:17 [gkatsev]
- nigel: how did they do it?
- 04:51:25 [gkatsev]
- atai: I can find out and tell everyone
- 04:51:36 [gkatsev]
- glenn: take a look at the minutes, I think there was a presentation
- 04:51:41 [gkatsev]
- nigel: any other points?
- 04:52:08 [gkatsev]
- atsushi: do we need a CfC?
- 04:52:25 [gkatsev]
- nigel: any resolution has a 2 week period for comments
- 04:52:40 [gkatsev]
- ... two ways for resolutions, record a resolution from a call/meeting and timer starts then
- 04:52:50 [gkatsev]
- ... alternatively, a CfC in an email
- 04:53:04 [gkatsev]
- ... when sending minutes out, mention decision period to get objections in
- 04:53:09 [gkatsev]
- ... no need to do both
- 04:53:24 [gkatsev]
- atsushi: should I wait for 10 days?
- 04:53:33 [gkatsev]
- nigel: depends on the kind of resolution
- 04:53:40 [gkatsev]
- ... there needs to have some editorial work
- 04:53:51 [gkatsev]
- glenn: I don't think it should be published until the 10 days
- 04:54:00 [gkatsev]
- nigel: yes, you need to wait till the decision review period is done
- 04:54:09 [gkatsev]
- ... ttml topic is next
- 04:59:00 [cyril]
- scribe: cyril
- 04:59:13 [cyril]
- Topic: TTML2
- 04:59:57 [cyril]
- nigel: we have 5 open issues planned for TPAC
- 05:00:24 [nigel]
- -> https://github.com/w3c/ttml2/labels/tpac TPAC labelled TTML2 issues
- 05:01:10 [nigel]
- Topic: Remove application of tts:rubyPosition to ruby annotation text. ttml2#945
- 05:01:15 [nigel]
- github: https://github.com/w3c/ttml2/issues/945
- 05:01:54 [cyril]
- glenn: the request here is to remove application of ruby position from ruby annotation text
- 05:02:04 [cyril]
- ... but to leave it for ruby container text
- 05:02:15 [cyril]
- ... right now TTML2 says it applies to ruby container and text
- 05:02:33 [cyril]
- ... CSS is not very clear
- 05:02:54 [cyril]
- ... the original reason was because you can have text without a text ocntainer
- 05:03:00 [nigel]
- -> https://www.w3.org/TR/2014/WD-css-ruby-1-20140805/#propdef-ruby-position CSS ruby-position
- 05:03:05 [cyril]
- ... in that case you want to be able to specify position
- 05:03:13 [nigel]
- -> https://www.w3.org/TR/ttml2/#style-attribute-rubyPosition TTML2 tts:rubyPosition
- 05:03:21 [cyril]
- ... but you can only have one text annotation present if you don't have a text container
- 05:03:32 [cyril]
- ... so you cannot have one that says before and one that says after
- 05:03:55 [cyril]
- nigel: in terms of delta with CSS, CSS says applies to ruby annotation containers
- 05:04:07 [cyril]
- glenn: but a container says applicable to boxes not elements
- 05:04:29 [cyril]
- ... "ruby annotation containers are internal ruby boxes"
- 05:04:58 [cyril]
- ... there is some ambiguity in the language
- 05:05:23 [cyril]
- cyril: CSS spec is still in WD
- 05:05:36 [cyril]
- glenn: 5 year discrepancies between WD and ED
- 05:05:48 [cyril]
- ... the status of CSS specs in this area are not very firm
- 05:06:15 [cyril]
- glenn: what problem are we solving by removing it
- 05:06:20 [cyril]
- pal: let's match CSS
- 05:06:34 [cyril]
- glenn: but CSS has not updated the WD since t5 years
- 05:06:42 [cyril]
- pal: also there is no reason to let it apply to text
- 05:06:59 [cyril]
- glenn: but a text can have a text without text container
- 05:07:11 [cyril]
- pal: there is an implied one
- 05:07:20 [cyril]
- glenn: but there is no way to refer to it
- 05:08:58 [cyril]
- glenn: we could just refer to the definition of ruby test container
- 05:09:10 [cyril]
- ... in section 10.2.21.1
- 05:09:58 [cyril]
- pal: ruby position is inherited
- 05:11:08 [cyril]
- ... you never need to specify on ruby text
- 05:11:16 [cyril]
- ... because you can always specify on the container
- 05:11:27 [cyril]
- ... and it is inherited on the ruby text container
- 05:12:13 [atai]
- q+
- 05:12:55 [cyril]
- ack
- 05:13:29 [cyril]
- atai: from what I understand, the difference between CSS and TTML is that the ruby position can be specified on a different structural element?
- 05:13:38 [cyril]
- pal: no, it's only application
- 05:13:40 [gkatsev]
- q?
- 05:13:47 [gkatsev]
- ack atai
- 05:13:54 [cyril]
- ... CSS says it does not apply on text, just text container
- 05:14:17 [cyril]
- pal: removing it from text does not remove any functionality
- 05:14:59 [cyril]
- glenn: that's wrong, because you can specify it on a span ruby=text and it has the semantics of applying to that annotation text or the container that's implied that contains it
- 05:15:18 [cyril]
- ... if you removing it, it would not have any effect
- 05:16:12 [cyril]
- nigel: is it true that in order to get the same functionality if you don't allow on text, you'd have to create an explicit text container?
- 05:16:57 [cyril]
- pal: you can specify it on the ruby element, and it will inherit to the implied ruby text container
- 05:17:32 [cyril]
- glenn: that doesn't deal with content already fielded that is putting ruby position on ruby annotation text elements
- 05:18:16 [cyril]
- pal: in the order of priority, it is not the most important feature
- 05:19:04 [cyril]
- glenn: do you agree that if we remove the ability, we are breaking content?
- 05:19:24 [cyril]
- ... it does make a technical change
- 05:19:55 [cyril]
- atai: we do not need a resolution today
- 05:20:09 [cyril]
- ... but we should agree to align with CSS whenever possible
- 05:20:43 [cyril]
- cyril: it's difficult to align with something not stable
- 05:20:55 [cyril]
- nigel: should we tell CSS to do the way we do it?
- 05:20:59 [cyril]
- glenn: yes
- 05:21:20 [cyril]
- atsushi_: i18n and CSS is working on updating the CSS spec
- 05:21:35 [cyril]
- ... to finalize the element structure
- 05:21:46 [cyril]
- glenn: it's not the structure in this case, but on the property
- 05:22:03 [cyril]
- nigel: if this work changes the element structure this would have an effect
- 05:22:15 [cyril]
- glenn: I doubt it would change the element structure, just the style definition
- 05:22:30 [cyril]
- nigel: does that mean we have a place to contribute this idea?
- 05:22:51 [cyril]
- atsushi_: current HTML does not have rtc
- 05:23:00 [cyril]
- ... that may be why there is a difference
- 05:23:17 [cyril]
- nigel: if they did not have a rtc, how do they apply ruby position
- 05:23:24 [cyril]
- atsushi_: they do it on rt
- 05:23:43 [cyril]
- nigel: we should get alignment with CSS by having them apply it to rtc
- 05:23:50 [nigel]
- s/rtc/rt
- 05:24:15 [cyril]
- nigel: anybody wants to take the action?
- 05:24:31 [cyril]
- atai: do you want to wait until the i18n work is finalized?
- 05:24:34 [cyril]
- atsushi_: yes
- 05:24:39 [cyril]
- atai: makes sense to me
- 05:24:48 [cyril]
- glenn: I will file an issue with the CSS WG
- 05:25:06 [cyril]
- atsushi_: we want to intrduce rtc and tabular ruby
- 05:25:17 [cyril]
- ... if we do that, it might be easier for every one
- 05:25:27 [cyril]
- atai: as a group, we should align
- 05:26:33 [cyril]
- cyril: we should make sure TTWG, CSS and I18N are all discussing the same thing
- 05:28:04 [nigel]
- -> https://github.com/w3c/ttwg/issues/69 Action on Glenn
- 05:28:43 [nigel]
- SUMMARY: Issue not time critical for us, work alongside CSS and i18n to get an aligned solution across TTML and CSS.
- 05:29:34 [cyril]
- example of Cap2TT output: https://raw.githubusercontent.com/skynav/ttt/master/ttt-cap2tt/src/test/resources/com/skynav/cap2tt/app/imsc11/test-015-ruby-position.expected.xml
- 05:30:01 [nigel]
- Topic: The set element is included in [resolve computed styles]. ttml2#950
- 05:30:08 [nigel]
- github: https://github.com/w3c/ttml2/issues/950
- 05:34:19 [cyril]
- glenn: after discussions, I said we could remove it
- 05:34:45 [cyril]
- pal: I think it was added as an error when going from TTML1 and TTML2 and so it should be removed
- 05:35:02 [cyril]
- glenn: we could not remove set and not remove animate
- 05:35:22 [cyril]
- nigel: Pierre says is an editorial and Glenn says it can't be tested
- 05:35:35 [cyril]
- pal: it was introduced by mistake and we should remove it
- 05:35:55 [cyril]
- glenn: I assume it was not an accident
- 05:36:37 [cyril]
- ... if we cannot test the removal, why remove it given the editorial pain
- 05:36:58 [cyril]
- pal: the goal was not to create a divergence between TTML1 and TTML2
- 05:37:33 [cyril]
- ... it's only a spec divergence
- 05:37:59 [cyril]
- ... I checked the differences in algorithms in TTML1 and TTML2 and this one stood out
- 05:38:35 [cyril]
- glenn: it's a change in a normative section
- 05:38:50 [cyril]
- cyril: can we ask to go through the editing work to see if there is any problem?
- 05:38:57 [cyril]
- glenn: I think we have done that
- 05:39:05 [cyril]
- ... and I said I am ready to remove them
- 05:40:14 [cyril]
- pal: let's keep the issue open
- 05:40:19 [cyril]
- glenn: fine
- 05:42:23 [cyril]
- SUMMARY: defer this for the time being and don't make this a dependency for TTML2 2nd edition, removed from the milestone
- 05:42:32 [cyril]
- Topic: Equivalence between tts:textDecoration="none" and "noUnderline noLineThrough noOverline" #1138
- 05:42:39 [cyril]
- github: https://github.com/w3c/ttml2/issues/1138
- 05:43:59 [cyril]
- nigel: in practice right now they are the same
- 05:45:32 [cyril]
- cyril: in this case, example 2 and 3 should give the same result?
- 05:45:33 [cyril]
- nigel: yes
- 05:45:50 [cyril]
- ... but if this was CSS it wouldn't be the same
- 05:46:26 [cyril]
- ... example 2 the textDecoration would be displayed
- 05:46:43 [cyril]
- ... example 3 is not possible in CSS because there are no values equivalent to no*
- 05:46:48 [cyril]
- ... you just can't do it
- 05:47:11 [cyril]
- ... once underlined has been applied at a parent level, you cannot un-apply it
- 05:48:26 [cyril]
- glenn: in TTML, it does punch a hole
- 05:48:43 [cyril]
- pal: is none identical to specifying the 3 no*
- 05:48:47 [cyril]
- glenn: yes
- 05:49:35 [cyril]
- cyril: at least we need a note that none here behaves differently from none in CSS
- 05:50:05 [cyril]
- glenn: the no versions are also different
- 05:50:27 [cyril]
- cyril: because you can undo them and not in CSS
- 05:50:31 [cyril]
- glenn: yes
- 05:50:42 [cyril]
- ... this is a feature where we are diverging from CSS
- 05:50:50 [cyril]
- ... that does not mean you cannot map TTML to CSS
- 05:51:02 [cyril]
- pal: it is not inherited in CSS
- 05:52:23 [cyril]
- nigel: the only way to get rid of the text decoration is to use an inline block
- 05:53:57 [cyril]
- nigel: we need a note to explain that none is equivalent to no*
- 05:54:13 [cyril]
- ... and in the semantic derivation that there are differences (inheritance behavior
- 05:54:33 [cyril]
- glenn: we could put it directly in the text decoration definition
- 05:55:01 [cyril]
- pal: 2 different notes: TTML-level and CSS/TTML difference
- 05:55:35 [cyril]
- SUMMARY: we agree with having 2 notes, and let the editor decide where they go
- 05:55:58 [cyril]
- Topic: Ruby constraints cannot be validated prior to ISD construction #1140
- 05:56:04 [cyril]
- github: https://github.com/w3c/ttml2/issues/1140
- 05:58:19 [cyril]
- pal: the problem is that the constraints are expressed based on properties not elements
- 05:58:29 [cyril]
- ... so you cannot validate them until you are in an ISD
- 05:58:39 [cyril]
- ... we have spans that behave like elements
- 06:00:10 [cyril]
- ... there are 3 options: we can say validation is done after ISD; we can constrain the application of a style resolution such that you can validate before style resolution; or say it was a mistake and change it to elements
- 06:00:19 [cyril]
- glenn: I prefer option 1
- 06:00:29 [atai]
- atai has joined #tt
- 06:00:51 [cyril]
- pal: condition has a problem that we don't have a model that says when it's executed
- 06:01:29 [cyril]
- nigel: there is no disagreement that has to be after ISD construction
- 06:01:38 [cyril]
- pal: this requires a huge change in IMSC.js
- 06:02:10 [cyril]
- nigel: there are 2 ways you can modify a property, but set/animate or by initials
- 06:02:25 [cyril]
- glenn: the PR makes them non animatable
- 06:03:32 [cyril]
- glenn: in TTT it validates after ISD construction
- 06:04:19 [cyril]
- pal: what I would like is them to be elements
- 06:04:23 [cyril]
- cyril: it's too late
- 06:05:16 [cyril]
- pal: the way it is specified today is terrible
- 06:06:04 [cyril]
- nigel: I don't see any advantage in making them not alterable by initial
- 06:06:16 [cyril]
- ... the conditional one has also some problems
- 06:06:29 [cyril]
- pal: yes, conditional has other problems
- 06:07:26 [cyril]
- nigel: the answer to the question in the issue, is yes that is the intent
- 06:07:44 [cyril]
- cyril: should we close the issue with no change?
- 06:07:47 [cyril]
- nigel: yes
- 06:08:13 [cyril]
- glenn: do we want to let the initial change the initial value from none to ruby?
- 06:08:53 [cyril]
- cyril: it's up to authors not to do crazy things
- 06:09:00 [cyril]
- glenn: I'm ok with that
- 06:09:16 [cyril]
- RESOLUTION: we close the issue with no action
- 06:10:22 [nigel]
- SUMMARY: Yes. we confirm that validation of ruby constraints can only happen after ISD construction.
- 06:10:55 [cyril]
- Topic: Clarify luminance gain prose (#1117). #1156
- 06:11:03 [cyril]
- github: https://github.com/w3c/ttml2/pull/1156
- 06:17:05 [cyril]
- nigel: I had a philosphical debate about "determine"
- 06:17:14 [cyril]
- pal: I prefer "determine"
- 06:20:33 [cyril]
- glenn: I can take out the cd/m2 unit
- 06:20:44 [cyril]
- glenn: the other comment I'm not sure it's good
- 06:21:17 [cyril]
- pal: fine, you can ignore it, it is not that important
- 06:22:32 [cyril]
- SUMMARY: Glenn to update the PR to remove the extraneous units and Pierre to approve, and Glenn to merge
- 06:22:50 [cyril]
- Topic: FPWD to TTML2 2nd ed
- 06:23:09 [cyril]
- nigel: looking at the issues, can we move to FPWD ?
- 06:23:18 [cyril]
- ... there are 10 open substantive ones
- 06:23:35 [cyril]
- ... 5 issues without PR open
- 06:25:36 [cyril]
- pal: the goal of FPWD is to get to HR started
- 06:25:44 [inamori_]
- inamori_ has joined #tt
- 06:25:53 [cyril]
- nigel: this is a REC document, the path is not to go to FPWD
- 06:26:13 [cyril]
- [looking at process]
- 06:27:21 [cyril]
- pal: we can just ask people to do HR on the ED
- 06:27:33 [cyril]
- glenn: can we make changes after HR has started?
- 06:27:43 [cyril]
- ... so I need to prepare a list of changes?
- 06:27:45 [cyril]
- nigel: yes
- 06:30:55 [cyril]
- SUMMARY: Glenn to prepare list of changes (editorial and substantive changes) and Nigel to initiate horizontal review based on Editor's Draft
- 06:34:11 [nigel]
- Topic: Break until 1600
- 06:37:03 [ericc]
- ericc has joined #tt
- 06:52:03 [inamori_]
- inamori_ has joined #tt
- 06:59:42 [pal]
- pal has joined #tt
- 07:02:44 [nigel]
- Topic: Karaoke Extensions
- 07:02:49 [nigel]
- scribe: nigel
- 07:03:48 [cyril]
- cyril has joined #tt
- 07:03:52 [nigel]
- Cyril: There are a number of open issues
- 07:04:04 [nigel]
- -> https://github.com/w3c/tt-module-karaoke/issues open issues on the karaoke module
- 07:05:12 [nigel]
- -> https://github.com/w3c/tt-reqs/wiki/Karaoke-Feature-Explainer Karaoke explainer
- 07:05:37 [nigel]
- -> https://w3c.github.io/tt-module-karaoke/ Karaoke draft specification
- 07:06:28 [cyril]
- https://github.com/w3c/tt-reqs/issues/9
- 07:06:49 [nigel]
- Cyril: To start with the requirements, that's in tt-reqs issue 9
- 07:07:08 [nigel]
- .. Reminder: we began working on these requirements first. Reviewing them:
- 07:07:13 [nigel]
- .. 2 types:
- 07:07:30 [nigel]
- .. 1. To add more semantics to a document to be processed independently of the styles, which may or may not be in the document.
- 07:07:44 [nigel]
- .. Important - you can go deeply into details like the trajectory of the bouncing ball.
- 07:07:54 [nigel]
- .. Can get very verbose for each event individually.
- 07:08:16 [nigel]
- .. Netflix wanted to specify timing first then secondarily styles that could be in the document or overridden by the presentation processor.
- 07:08:48 [nigel]
- .. For example to allow Netflix to use the same style bouncing ball for all shows.
- 07:09:02 [nigel]
- .. At the same time, allow for specific styling in the documents if you like.
- 07:09:09 [nigel]
- rrsagent, make minutes
- 07:09:09 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/18-tt-minutes.html nigel
- 07:09:21 [nigel]
- .. That's how we proposed the requirements initially.
- 07:10:16 [nigel]
- .. Then the explainer lists possible solutions. [iterates through the options in the document]
- 07:10:29 [nigel]
- .. Using animate increased the verbosity of the representation.
- 07:11:05 [nigel]
- .. After this we proposed the current spec.
- 07:11:14 [nigel]
- .. The feedback initially was that using new elements was not a good idea.
- 07:11:39 [nigel]
- .. What I tried to do for the first version was see what the minimum amount of new attributes is to meet the requirements.
- 07:11:51 [nigel]
- .. I also wanted to do the minimum to keep compatibility with IMSC 1.x
- 07:12:19 [nigel]
- .. Does it make any difference if the features are expressed as new elements or new attributes?
- 07:12:38 [nigel]
- Pierre: What's the most efficient? Using ruby as an example, introducing an element would have been much better.
- 07:12:45 [nigel]
- .. I don't have a strong opinion a priori.
- 07:13:11 [nigel]
- Cyril: The specification starts with a model, which is kept simple.
- 07:13:21 [nigel]
- .. Imagine a small section of a movie with a song where karaoke mode is needed.
- 07:13:35 [nigel]
- .. Or another example is the whole document only represents that song.
- 07:14:12 [nigel]
- .. The first approach is a karaoke attribute in some namespace.
- 07:14:30 [nigel]
- .. The intention was to specify that here in this section the semantics of karaoke apply and the processor can do its thing.
- 07:14:35 [nigel]
- .. Then you need to know what can be overridden.
- 07:14:57 [nigel]
- .. That is given by the karaokeMode attribute and the set element to provide the inner times within the karaoke.
- 07:15:23 [nigel]
- .. The karaokeMode tells you what kind of change to do, e.g. color, which changes the color of the text with the time.
- 07:15:34 [nigel]
- .. For example a color sweep.