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.