This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From http://lists.w3.org/Archives/Public/public-texttracks/2014May/0118.html "With respect to roll-up, caption line lengths in the US on TV are pretty limited" This means that each cue is a single line which is not expected to wrap. To handle the case where the font is unexpectedly large or the content isn't so well authored, a region could be limited by number of cues instead of lines, without changing the behavior in the typical case.
Discussion at FOMS found it's a corner case and can wait to v2.
You can't go back and change this in v2, if you have VTTRegion.lines in v1 then that's the model you have to support in v2 as well.
Fair enough. The perception of the room was, however, that it's a corner case that will go wrong in any case. I'm easy either way. Developer input required.
The "limit by lines" model only works on the assumption that each cue will be one line. Under that assumption it would be equivalent to state the limit in number of cues, except that this also would allow the region to grow as required when the assumption turns out to be false, likely due to increased font size.
(In reply to Philip Jägenstedt from comment #4) > The "limit by lines" model only works on the assumption that each cue will > be one line. That's not true. A cue with multiple lines will simply roll off faster, which is how it works on TV, too. > Under that assumption it would be equivalent to state the limit > in number of cues, except that this also would allow the region to grow as > required when the assumption turns out to be false, likely due to increased > font size. Increased font size and ruby annotations don't change the number of lines, just the line height.
(In reply to Silvia Pfeiffer from comment #5) > (In reply to Philip Jägenstedt from comment #4) > > The "limit by lines" model only works on the assumption that each cue will > > be one line. > > That's not true. A cue with multiple lines will simply roll off faster, > which is how it works on TV, too. At least CEA-608 is monospace and with no automatic line wrapping. With WebVTT in browsers, the combination of %-based positioning and user overrides for the font size means that the author cannot fully predict line wrapping, and in the limit "roll off faster" means that some text will never be visible at all. > > Under that assumption it would be equivalent to state the limit > > in number of cues, except that this also would allow the region to grow as > > required when the assumption turns out to be false, likely due to increased > > font size. > > Increased font size and ruby annotations don't change the number of lines, > just the line height. Increasing the font size can result in a line wrapping and thus more lines of text rendered. It doesn't change the number of lines in the region, and that's the problem.
(In reply to Philip Jägenstedt from comment #6) > (In reply to Silvia Pfeiffer from comment #5) > > (In reply to Philip Jägenstedt from comment #4) > > > The "limit by lines" model only works on the assumption that each cue will > > > be one line. > > > > That's not true. A cue with multiple lines will simply roll off faster, > > which is how it works on TV, too. > > At least CEA-608 is monospace and with no automatic line wrapping. With > WebVTT in browsers, the combination of %-based positioning and user > overrides for the font size means that the author cannot fully predict line > wrapping, and in the limit "roll off faster" means that some text will never > be visible at all. So let's talk about line wrapping. Typically, roll-up captions are authored such that the lines in a cue are quite short, so even if you increase the font size, it will be an exception to see a line wrap. As we do with positioned cues that break out of the viewport, we could consider disabling automatic line wrapping for cues in a region. It's a corner case and therefore probably ok. That means that the number of lines that a cue was authored with will remain fixed ad "limit by lines" works for multi-line cues, too. > > > > Under that assumption it would be equivalent to state the limit > > > in number of cues, except that this also would allow the region to grow as > > > required when the assumption turns out to be false, likely due to increased > > > font size. > > > > Increased font size and ruby annotations don't change the number of lines, > > just the line height. > > Increasing the font size can result in a line wrapping and thus more lines > of text rendered. It doesn't change the number of lines in the region, and > that's the problem.
(In reply to Silvia Pfeiffer from comment #7) > (In reply to Philip Jägenstedt from comment #6) > > (In reply to Silvia Pfeiffer from comment #5) > > > (In reply to Philip Jägenstedt from comment #4) > > > > The "limit by lines" model only works on the assumption that each cue will > > > > be one line. > > > > > > That's not true. A cue with multiple lines will simply roll off faster, > > > which is how it works on TV, too. > > > > At least CEA-608 is monospace and with no automatic line wrapping. With > > WebVTT in browsers, the combination of %-based positioning and user > > overrides for the font size means that the author cannot fully predict line > > wrapping, and in the limit "roll off faster" means that some text will never > > be visible at all. > > So let's talk about line wrapping. Typically, roll-up captions are authored > such that the lines in a cue are quite short, so even if you increase the > font size, it will be an exception to see a line wrap. As we do with > positioned cues that break out of the viewport, we could consider disabling > automatic line wrapping for cues in a region. It's a corner case and > therefore probably ok. That means that the number of lines that a cue was > authored with will remain fixed ad "limit by lines" works for multi-line > cues, too. For positioned cues we clamp the size so that position+size<=100, but we don't do anything with the line wrapping rules. Given that the region can have a background and its size is fixed, it seems to me that authors will want to decrease the size of the region until the text just barely fits without wrapping, for aesthetic purposes. You would have to leave a lot of margin to avoid line wrapping for all reasonable font sizes, after all. That this all seems to work out well enough with CEA-608/708 doesn't give me great confidence, because there the sizes are given in rows and columns and I think the windows (regions) are scaled around their anchors points if needed. That's quite different from a fixed region size combined with unpredictable font size.
Rollup captions are typically left aligned and cover less than half the screen. That's why it works for CEA6/708. Also, in CEA6/708, I don't think the number of rows and columns changes with font size - I really don't know how it handles font changes. It certainly doesn't add lines when the line overflows.
(In reply to Silvia Pfeiffer from comment #9) > Rollup captions are typically left aligned and cover less than half the > screen. That's why it works for CEA6/708. Do you also typically get a background on the whole window (region), so that cover a lot more of the video than typically needed? The roll-up captions that I have seen have had the background only on the text. Having a stable background box in combination with unpredictable font sizes is the core problem here.
(In reply to Philip Jägenstedt from comment #10) > Do you also typically get a background on the whole window (region), so that > cover a lot more of the video than typically needed? The roll-up captions > that I have seen have had the background only on the text. Having a stable > background box in combination with unpredictable font sizes is the core > problem here. Yeah, only the text part has a background. This is making me re-think the "cue box" as the bounding box ... it should really always just be a background on the actual text... hmmm
It seems like there are at least three different styles in existing captions: 1. Background on just the text, like what WebVTT currently has but with padding also before and after line breaks. 2. Background on the bounding box of the text. 3. A stable background box for roll-up captions.