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 19836 - WebVTT: allow float values as percentages in cue settings
Summary: WebVTT: allow float values as percentages in cue settings
Status: RESOLVED FIXED
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: 2012-11-02 22:28 UTC by Silvia Pfeiffer
Modified: 2014-01-27 20:37 UTC (History)
6 users (show)

See Also:


Attachments

Description Silvia Pfeiffer 2012-11-02 22:28:11 UTC
As I was creating more details for the conversion from CEA-608/708 caption format specifications to WebVTT, I've come across a need to specify real numbers and not just integers as percentage values for the "line" cue setting:

http://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#positioning-in-cea-608

Can we allow floating-point numbers as percentage values for line and position cue settings?
Comment 1 Ian 'Hixie' Hickson 2012-11-21 19:21:10 UTC
In a 1080p setting, 1% is 10 pixels, and the font size at 5% is 50 pixels. Does it really matter that you can't position it more accurately than 10 pixels?

I guess it's not a big deal, but it does have knock-on effects throughout the API.
Comment 2 Silvia Pfeiffer 2012-11-21 20:05:44 UTC
It's not just the 10px, but it's a cumulative effect.

For example, CEA-608 defines 15 lines on 80% of the video height. That's 5.33% line height. If that gets reduced to 5%, then we end up with an extra line. I have no means of getting to exactly 15 lines.
Comment 3 Ian 'Hixie' Hickson 2012-11-22 00:14:12 UTC
Just round instead of truncating.
Comment 4 Silvia Pfeiffer 2012-11-22 00:44:19 UTC
That just creates an uneven distribution of lines on top of the video with different gaps.
Comment 5 Ian 'Hixie' Hickson 2012-11-22 07:13:32 UTC
So just use WebVTT's line feature, instead of trying to use CEA-608. :-)

Trying to coerce one format into another format is pointless. If you want to support CEA-608, then just implement it. WebVTT isn't supposed to be a format that implements other formats. It's supposed to be subtitles for the Web.
Comment 6 Silvia Pfeiffer 2012-11-22 07:29:59 UTC
It doesn't matter if it's CEA-608 or anything else that I try to implement - I should be able to decide how many lines of text I want displayed on top of my video and be able to position my text exactly on those lines. The line numbering doesn't help for this, because with line numbers the browser and the font decide how much distance there is between lines.

The crux is: if I want exact placement based on percentage, then that should have a sufficiently large resolution to place exactly - if possible down to the pixel level. For this we need floats as percentage.
Comment 7 Loretta Guarino Reid 2014-01-10 21:48:11 UTC
(In reply to Silvia Pfeiffer from comment #6)
> It doesn't matter if it's CEA-608 or anything else that I try to implement -
> I should be able to decide how many lines of text I want displayed on top of
> my video and be able to position my text exactly on those lines. The line
> numbering doesn't help for this, because with line numbers the browser and
> the font decide how much distance there is between lines.
> 
> The crux is: if I want exact placement based on percentage, then that should
> have a sufficiently large resolution to place exactly - if possible down to
> the pixel level. For this we need floats as percentage.

 +1 to the need for floats as percentage values.
Comment 8 Philip J├Ągenstedt 2014-01-27 04:39:47 UTC
I am currently reviewing https://github.com/w3c/webvtt/pull/18 which refers to this bug.

This bug only argues for greater precision for line, but sure, it would be silly to only fix line and not the other two.

The current spec limits the range of position and size to 0-100, so those can be packed efficiently to reduce memory. Going to double for all of these attributes gives us way more precision than we need, wasting memory.

I think we should either go with float, or something silly like allowing a single extra decimal, giving us a precision of 1000, if that is sufficient for the use case.
Comment 9 Silvia Pfeiffer 2014-01-27 06:34:53 UTC
It's also good to be consistent considering bug 23865
Comment 10 Silvia Pfeiffer 2014-01-27 06:37:26 UTC
Given the recommendation to use double in WebIDL [1] and the fact that there is not a single use of "float" in the APIs of the HTML spec, I suggest we stay consistent in our WebIDL with "double".

[1] http://heycam.github.io/webidl/#idl-float