IRC log of tt on 2015-10-28

Timestamps are in UTC.

23:41:01 [RRSAgent]
RRSAgent has joined #tt
23:41:01 [RRSAgent]
logging to
23:41:02 [olivier]
olivier has joined #tt
23:41:03 [trackbot]
RRSAgent, make logs public
23:41:03 [Zakim]
Zakim has joined #tt
23:41:03 [akitsugu]
akitsugu has joined #tt
23:41:05 [trackbot]
Zakim, this will be TTML
23:41:05 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
23:41:06 [trackbot]
Meeting: Timed Text Working Group Teleconference
23:41:06 [trackbot]
Date: 28 October 2015
23:41:24 [nigel]
chair: nigel
23:42:27 [nigel]
Present: olivier, andreas, akitsugu, nigel, glenn, zcorpan, pierre
23:42:32 [glenn]
glenn has joined #tt
23:42:36 [nigel]
rrsagent, this meeting spans midnight
23:48:20 [nigel]
scribe: nigel
23:48:28 [nigel]
Topic: Introductions
23:48:35 [zcorpan]
Simon Pieters, Opera
23:48:42 [nigel]
Nigel Megitt, BBC
23:48:48 [olivier]
Olivier Thereaux, BBC (obs)
23:48:50 [glenn]
Glenn Adams, Skynav
23:48:57 [akitsugu]
Akitsugu Baba , NHK
23:49:20 [dae]
dae has joined #tt
23:49:25 [nigel]
s/NHK/NHK (obs)
23:49:38 [dae]
prsent+ dae
23:49:42 [dae]
present+ dae
23:49:54 [nigel]
s/prsent+ dae/
23:50:07 [atai2]
atai2 has joined #tt
23:50:14 [dae]
Dae: Netflix
23:50:36 [atai2]
Institut für Rundfunktechnik
23:50:56 [nigel]
s/Institut/Andreas Tai, Institut
23:52:25 [nigel]
pal: Pierre Lemieux, MovieLabs
23:52:43 [nigel]
Topic: Agenda Review
23:53:09 [nigel]
nigel: Goes through agenda. Any proposals to change it?
23:53:26 [pal]
pal has joined #tt
23:53:30 [nigel]
pal: What are we trying to achieve on each of these topics?
23:54:02 [nigel]
atai2: Can we go for TTML <--> WebVTT mapping immediately after lunch?
23:54:18 [nigel]
... Also tomorrow morning before IMSC can we have a session on industry feedback on TTML?
23:54:50 [nigel]
... Apart from the mapping, are there any other topics we should cover re WebVTT?
23:55:10 [nigel]
zcorpan: I thought also we should have a session on WebVTT.
23:55:26 [nigel]
nigel: When would be a good time to do that?
23:55:45 [nigel]
zcorpan: Maybe this afternoon. The main thing I want to talk about is how we publish
23:56:00 [nigel]
... working drafts, and having a single URL for ED and /TR WD snapshot.
23:56:33 [nigel]
nigel: That fits with the tools discussion..
23:56:37 [nigel]
zcorpan: Can we move that to today?
23:58:57 [nigel]
nigel: I wanted plh to come along for the tools part.
00:30:20 [nigel]
Topic: HTMLCue proposal
00:32:25 [nigel]
nigel: Introduces topic - history of this coming from Glenn and Erik Lindstrom of Opera.
00:32:54 [nigel]
... The idea being to use the timing abilities of TextTrackCue to do generic HTML presentation.
00:33:15 [nigel]
... We sent a proposal to WHATWG and in summary the response was that there are
00:33:24 [nigel]
... things that we need to think about, and possible unintended consequences.
00:33:43 [nigel]
atai2: We also wanted to get developer/implementor views, which we did yesterday.
00:33:59 [nigel]
nigel: Yes, yesterday I ran a breakout session on the topic, minutes at
00:34:07 [nigel]
00:34:14 [nigel]
... which had good attendance.
00:35:47 [nigel]
zcorpan: There were a few misunderstandings. One was that the HTMLSpec had a
00:36:05 [nigel]
... 250ms potential delay for notifying when a cue was rendered in Javascript. In fact
00:36:19 [nigel]
... that was an unrelated event called timeUpdate. There are separate cue enter and
00:36:33 [nigel]
... cue leave that have accurate timings, so Javascript events aren't going to miss a cue.
00:37:07 [nigel]
... The other conclusion was that instead of using HTMLCue it is a better idea to have
00:37:22 [nigel]
... the js parse the cue data and then render it on top of the video and not have the
00:37:26 [nigel]
... browser do that.
00:37:51 [nigel]
... Going back a step, one of the reasons is that the track element is not capable of
00:38:04 [nigel]
... executing scripts currently, or of referencing external references from the subtitle
00:38:16 [nigel]
... track itself. The assumption is, like the img element, including a subtitle file is safe
00:38:27 [nigel]
... and cannot do anything. If we allow html inside a subtitle track it can suddenly do
00:38:39 [nigel]
... lots of things that could be a security or privacy problem or both, so it is unlikely
00:38:47 [nigel]
... that browser vendors are going to jump at implementing it.
00:38:57 [nigel]
glenn: Of course we're not making the assumption that it is necessary to process
00:39:09 [nigel]
... scripts or fetch resources. It's possible to put restrictions on how the HTML is
00:39:11 [nigel]
... processed
00:39:25 [nigel]
zcorpan: As Ted pointed out, safely subsetting HTML is extremely hard and it is
00:39:39 [nigel]
... probably a bad idea to do that - it's easier and safer to start from zero and add things.
00:39:52 [nigel]
glenn: We already know about flags like sandbox flags that control the context.
00:40:05 [nigel]
... It would be one thing if we were introducing a whole new type of sandbox rather than
00:40:18 [nigel]
... using the existing mechanisms that are already implemented. For example, if we
00:40:32 [nigel]
... triggered it as a sandboxed feature, would that raise the same issues?
00:40:47 [nigel]
zcorpan: The current sandbox was not designed as a be-all security feature, but as a
00:41:04 [nigel]
... defence in depth feature for when untrusted content is also sanitised on the server,
00:41:18 [nigel]
... to catch bugs. Also there is no sandbox value that does what we want to do. It will
00:41:29 [nigel]
... still fetch external resources for instance. So we still have the problem of defining
00:41:34 [nigel]
... what is the safe subset of HTML.
00:41:52 [nigel]
atai2: I think there are 2 different views - one is on the feasibility of the technical solution,
00:42:05 [nigel]
... and the other is how to proceed. We wanted to get browser side perspective,
00:42:24 [nigel]
... but nobody stood up from the browser community to say possibly this is feasible
00:42:40 [nigel]
... instead the view was to use WebVTT with metadata payload and have js then
00:42:50 [nigel]
... render the HTML. For us it would be important to decide what to do. One proposal
00:43:05 [nigel]
... would be to follow this concept and see if that works for our use case.
00:43:26 [nigel]
zcorpan: As an aside, the same technique would work for ad display also.
00:44:46 [nigel]
nigel: This technique is to use a TextTrack whose kind attribute is metadata, then have
00:45:06 [nigel]
... javascript pull out the HTML data and render it on the onenter(). The objection I raised
00:45:35 [nigel]
... was that this subverts the purpose of the kind attribute and prevents accessible
00:45:52 [nigel]
... solutions from knowing that tracks are intended for display for accessibility.
00:46:12 [nigel]
... There was an action that Ted proposed to raise a feature request on this...
00:46:28 [nigel]
zcorpan: Yes, I can take an action item on that, to expose the accessibility preferences
00:46:46 [nigel]
... to Javascript so that scripts can honour the user preference.
00:47:45 [nigel]
Action: zcorpan Raise an issue on the HTML spec to add an API to expose the user preference
00:47:46 [trackbot]
Created ACTION-440 - Raise an issue on the html spec to add an api to expose the user preference [on Simon Pieters - due 2015-11-05].
00:51:45 [nigel]
nigel: From an architectural perspective it still seems neater to me to keep TextTrack kind
00:51:58 [nigel]
... for its intended purpose and to use different cue types to express different presentation
00:52:15 [nigel]
... semantics - VTTCue is great for expressing how VTT cues should be presented
00:52:21 [nigel]
... but not for other types.
00:52:35 [nigel]
zcorpan: I thought of another approach for HTML - to allow more than one value in the
00:52:53 [nigel]
... kind attribute, for example "metadata subtitles" where the term "metadata" just means
00:53:08 [nigel]
... 'not for direct rendering by the UA'.
00:53:23 [nigel]
atai2: I think we need to decide where to take this forward.
00:55:19 [nigel]
nigel: It feels too soon to stop this now - there's a suggestion from another browser manufacturer that they would be interested in doing some work here.
00:55:33 [nigel]
atai2: For me the next step is to analyse further the proposal to use metadata in this way.
00:58:06 [nigel]
nigel: It's worth noting that dash.js already uses this approach. They had to use VTTCue because it was the only text track cue that is implemented.
00:58:24 [nigel]
zcorpan: It's not overloading VTTCue - it was actually designed to support that.
00:58:40 [nigel]
atai2: Another part of the proposal is to use a VTT file to store the payload.
00:58:53 [nigel]
zcorpan: Yes, but you don't have to use a VTT file - you can get the cue data from anywhere
00:59:15 [nigel]
... XHR, a WebSocket, or wherever. You just need a mapping between a cue and the payload.
01:00:55 [nigel]
nigel: So we have one action - any others?
01:01:08 [nigel]
atai2: It would be good to look in depth at the approach and see how well it works.
01:01:18 [nigel]
zcorpan: If you have any questions on that I'd be happy to help.
01:01:38 [nigel]
nigel: That feels like a mini task force to go and think about this and generate a small
01:01:40 [nigel]
... document.
01:01:55 [nigel]
nigel: That's Andreas, Nigel and Simon.
01:02:36 [nigel]
Action: atai2 Kick off the analysis work on the VTTCue carrying HTML idea.
01:02:36 [trackbot]
Created ACTION-441 - Kick off the analysis work on the vttcue carrying html idea. [on Andreas Tai - due 2015-11-05].
01:03:50 [nigel]
Topic: TTML2 - Script layout, rubys etc.
01:08:36 [nigel]
01:09:11 [nigel]
... * ruby overhand
01:09:17 [nigel]
01:09:34 [nigel]
... * ruby overflow
01:09:40 [nigel]
... * ruby reserve
01:09:44 [nigel]
... * ruby offset
01:10:12 [nigel]
glenn: The use case for adding ruby markup to TTML2 was to support the lamba cap semantics.
01:10:31 [nigel]
... It turns out that there are a couple of edge cases that were not handled by CSS.
01:10:42 [nigel]
... In some cases CSS discussed them. In addition the Japanese Language Requirements
01:10:55 [nigel]
... document discussed them, and in others neither of them were discussed. We ended
01:11:36 [nigel]
... up defining 5 different style properties - the 4 as listed above and ruby overhang class
01:12:11 [nigel]
In the case at the above URL there's an example where the 6 ruby characters take more
01:12:28 [nigel]
... width than the base. So you need to know how to overhang. In the top example
01:12:41 [nigel]
... white space is added around the base to make the width match, so there's no overhang.
01:12:59 [nigel]
... In the next example (example 18) the text is allowed to overhang adjacent base
01:13:01 [nigel]
... characters.
01:13:12 [nigel]
s/In the case/glenn: In the case
01:13:27 [nigel]
glenn: CSS doesn't define a mechanism to control the behaviour of the rendering process
01:13:42 [nigel]
... Additionally there's ruby overflow, which comes up when you have the case of wider
01:14:02 [nigel]
... ruby than the base and the context is a line edge boundary. (Figure 19)
01:14:15 [nigel]
... Let's say you have a text alignment of start or left, then the base characters push up
01:14:39 [nigel]
... against the left edge. If the ruby text is wider than the base, and you specify a ruby
01:15:01 [nigel]
... alignment such as center. You can specify how the ruby box aligns with the base content.
01:15:18 [nigel]
... You can specify start, end, center, distribute space between, distribute space around.
01:15:34 [nigel]
... In this case if you want to center the ruby then you push the ruby box outside the line
01:16:00 [nigel]
... box to maintain the alignment. The base text has priority the text alignment. You have
01:16:26 [nigel]
... an over constrained environment, which causes the problem. There are two ways to
01:16:39 [nigel]
... resolve the overflow. You can relax the base text alignment and allow it to be pushed
01:16:54 [nigel]
... out away from the line edge so the ruby does not overflow. I call that shift base overflow.
01:17:08 [nigel]
... That maintains the alignment between ruby and base.
01:17:25 [nigel]
... The other way to do it is to keep the base alignment but relax the ruby alignment.
01:17:57 [nigel]
... I call that shift ruby. The third option I defined was overflow, which does not relax
01:18:09 [nigel]
... either constraint but allows the ruby to overflow the line area, in which case you have
01:18:22 [nigel]
... to use the tts:overflow property.
01:19:01 [nigel]
nigel: Do we need to strengthen any of the language in tts:overflow to cover this use
01:19:41 [nigel]
... case? Right now there are no 'SHALLs' in tts:overflow, only 'SHOULD's.
01:20:24 [nigel]
glenn: That's a good point. The question is here if you use overflow but the implementation
01:21:00 [nigel]
... is always clipping then you're going to lose that.
01:21:15 [nigel]
nigel: Do we know why there are only SHOULDs now?
01:21:27 [nigel]
glenn: My recollection is that we weren't sure if implementations could do clipping so we
01:21:30 [nigel]
... kept the language loose.
01:21:52 [nigel]
... The CSS spec says "This level of the specification does not provide a mechanism to control this behaviour."
01:22:08 [nigel]
... It turns out that this isn't sufficient for captions. We need a way to explicitly define this.
01:22:23 [nigel]
RRSAgent, make minutes
01:22:23 [RRSAgent]
I have made the request to generate nigel
01:23:08 [nigel]
atai2: So would the shift base extend the containing box?
01:23:21 [nigel]
glenn: shift base would insert white space, i.e. padding, on the inside of that box to
01:23:34 [nigel]
... move the base content across to maintain the ruby alignment that has been specified.
01:24:55 [nigel]
... Then there's a question about where you allow overhang - everywhere or dependent on
01:25:08 [nigel]
... the base. It turns out that the JLR document defines classes of characters where
01:25:16 [nigel]
... overhang is permissible and where it is not permissible.
01:25:52 [zcorpan]
zcorpan has joined #tt
01:26:06 [glenn]
01:26:27 [nigel]
glenn: This shows the case when the ruby text is no larger than the corresponding base.
01:26:56 [nigel]
... So there's no problem when the ruby is less than or equal to the base size. You get
01:27:08 [nigel]
... the problem when the ruby requires more inline space than the base.
01:28:05 [nigel]
... Fig 3.79 shows this. When you do allow overhang. In one case a hiragana ruby is
01:28:20 [nigel]
... permitted to overlap a hiragana base, but not on a kanji base - doing the latter could
01:28:43 [nigel]
... be misread as the ruby applying to the kanji character. Hence beneath figure 3.80
01:28:56 [nigel]
... the points a and b describe the rules.
01:29:12 [nigel]
... Fig 3.81 and 3.82 show this.
01:29:49 [nigel]
nigel: Is this based on language dependent rules or do we need syntax to define it?
01:30:02 [nigel]
glenn: Ruby is primarily used in Japanese, very rarely in Chinese and more rarely still
01:30:26 [nigel]
... in Korean. Technically one could use the same layout features in all of those languages.
01:30:39 [nigel]
... It's even potentially useful in other languages that don't normally use ruby, like for
01:31:00 [nigel]
... annotations, like a scholarly piece on Greek, "interlinear text". To handle the