This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22789 - WebVTT: Data model for line position should not include overlap avoidance
Summary: WebVTT: Data model for line position should not include overlap avoidance
Status: RESOLVED WORKSFORME
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Silvia Pfeiffer
QA Contact: This bug has no owner yet - up for the taking
URL:
Whiteboard: v1
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-24 06:25 UTC by Silvia Pfeiffer
Modified: 2014-01-28 11:17 UTC (History)
3 users (show)

See Also:


Attachments

Description Silvia Pfeiffer 2013-07-24 06:25:37 UTC
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.
Comment 1 Silvia Pfeiffer 2013-07-24 09:56:55 UTC
Also, the notion of "text track cue computed line position" is only used in the rendering section so it should be moved there completely.
Comment 2 Philip J├Ągenstedt 2014-01-28 08:28:44 UTC
(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.)
Comment 3 Silvia Pfeiffer 2014-01-28 11:17:44 UTC
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.