22789 2013-07-24 06:25:37 +0000 WebVTT: Data model for line position should not include overlap avoidance 2014-01-28 11:17:44 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified PC All RESOLVED WORKSFORME v1 P2 normal --- 1 silviapfeiffer1 silviapfeiffer1 mike philipj public-texttracks dave.null oldest_to_newest 91207 0 silviapfeiffer1 2013-07-24 06:25:37 +0000 The data model for line positioning is defined in: http://dev.w3.org/html5/webvtt/#dfn-text-track-cue-line-position If line is auto (i.e. not set), then the line position is determined based on the other text tracks that are showing. I have several issues with this approach: Firstly, it assumes that each cue is only one line long and thus adds "1" to the line position of every track. This is a faulty assumption. Secondly, it would be better to have the same overlap avoidance that applies to multiple cues within a track applied to all cues that are active at a certain point in time. I'm therefore suggesting to remove steps 4 - 10 of that algorithm. 91217 1 silviapfeiffer1 2013-07-24 09:56:55 +0000 Also, the notion of "text track cue computed line position" is only used in the rendering section so it should be moved there completely. 99276 2 philipj 2014-01-28 08:28:44 +0000 (In reply to Silvia Pfeiffer from comment #0) > The data model for line positioning is defined in: > http://dev.w3.org/html5/webvtt/#dfn-text-track-cue-line-position > > If line is auto (i.e. not set), then the line position is determined based > on the other text tracks that are showing. > > I have several issues with this approach: > > Firstly, it assumes that each cue is only one line long and thus adds "1" to > the line position of every track. This is a faulty assumption. Assuming the cues are rendered in the correct order then even if they are multi-line they should move due to overlap avoidance, so they should end up in the correct order. However, if that's true, I'm not sure why they can't all be placed at -1 to let the overlap algorithm do all the work. > Secondly, it would be better to have the same overlap avoidance that applies > to multiple cues within a track applied to all cues that are active at a > certain point in time. I think this is already the case, the rendering section already considers all the tracks together. > I'm therefore suggesting to remove steps 4 - 10 of that algorithm. To help illuminate this issue, can you show an example where the rendered result would be different and how removing these steps is better? (If there aren't any cases where this matters then of course the steps can be removed.) 99288 3 silviapfeiffer1 2014-01-28 11:17:44 +0000 This is a 18 months old and the line numbers probably don't apply any longer. I'm going to close this, since we are now discussion on list how to integrate the rendering algorithms. Whatever we come up with there should be applied and not this.