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 24037 - [WebVTT] Positioning boxes when snap-to-lines is false
Summary: [WebVTT] Positioning boxes when snap-to-lines is false
Status: NEW
Alias: None
Product: TextTracks CG
Classification: Unclassified
Component: WebVTT (show other bugs)
Version: unspecified
Hardware: PC Linux
: 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-12-09 21:04 UTC by Loretta Guarino Reid
Modified: 2014-05-13 13:01 UTC (History)
4 users (show)

See Also:


Attachments

Description Loretta Guarino Reid 2013-12-09 21:04:34 UTC
When adjusting the position of cue boxes, if a cue's text track cue snap-to-lines flag is not set, step 2 says 

"Position the boxes in boxes such that the point x% along the width of the bounding box of the boxes in boxes is x% of the way across the width of the video's rendering area, and the point y% along the height of the bounding box of the boxes in boxes is y% of the way across the height of the video's rendering area, while maintaining the relative positions of the boxes in boxes to each other."

I thought the line alignment and position alignment would be used to determine which point in the cue box is specified by the positions, rather than using the line and position values as the anchor points. Is the spec just lagging behind here?

The alignment values are used above in step 7 when computing the x-position and y-position. However, when we get to the step of adjusting the boxes, these values appear to be discarded and we use the algorithm described above.
Comment 1 Philip J├Ągenstedt 2014-01-27 08:34:31 UTC
Not sure that we've found agreement on how the position is supposed to work yet, but we should get the story straight for v1 at least.
Comment 2 Silvia Pfeiffer 2014-01-27 11:47:14 UTC
Yes, the rendering part still needs some clarifications.
Comment 3 Silvia Pfeiffer 2014-05-12 04:03:38 UTC
Point 11 and 12 of the rendering algorithm (Processing Model section) relate to the overlap avoidance, but with some cruft left over in point 11. I'll need to spend some time wading through it.
Comment 4 Philip J├Ągenstedt 2014-05-13 13:01:54 UTC
Silvia, have you made any changes to the overlap handling? What is the cruft that is left over?