Re: Unifying the rendering approach

On 18/02/2014 10:34, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

>On Tue, Feb 18, 2014 at 8:11 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>wrote:
>> On 18/02/2014 09:04, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
>>wrote:
>>
>>>On Tue, Feb 18, 2014 at 7:55 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>>wrote:
>>>> On 18/02/2014 07:48, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
>>>>wrote:
>>>>
>>>>>Here are some examples.
>>>>>
>>>>>1. Regular cues without region reference:
>>>>>
>>>>>These are the cues that were previously not rendered into a region,
>>>>>but would now be rendered into an anonymous region.
>>>>>
>>>>>Example file
>>>>>---
>>>>>WEBVTT
>>>>>
>>>>>Cue 1
>>>>>0:00:03.040 --> 0:00:15.302
>>>>>So, I just wanted to introduce you to W3C,
>>>>>
>>>>>Cue 2
>>>>>0:00:06.920 --> 0:00:15.302
>>>>>and to do so, I have some exciting information:
>>>>>
>>>>>Cue 3
>>>>>0:00:10.000 --> 0:00:15.302
>>>>>W3C has been acquired by Twitter.
>>>>>
>>>>>Cue 4
>>>>>0:00:13.800 --> 0:00:15.302 position:5%,start align:start size:30%
>>>>>line:5%,start
>>>>>[AUDIENCE GIGGLES]
>>>>>---
>>>>>
>>>>>Rendered at time 15.300 as in the attached regular_cues.png .
>>>>>
>>>>>This is the same rendering as we had before doing regions (keeping
>>>>>backwards compatibility). There is a single anonymous region and it
>>>>>contains all cues that are not associated with a named region. The
>>>>>region always covers the full viewport. Cues inside it try to avoid
>>>>>overlaps (how is yet to be clarified - for now let's assume it's done
>>>>>as before introducing an anonymous region). This is why cues 2 and 3
>>>>>move above their default position which is already occupied by cue1.
>>>>>
>>>>>
>>>>>2. Cues in a named region that is not scrolling:
>>>>>
>>>>>These are cues that are rendered into a region, but the region is
>>>>>non-scrolling.
>>>>>
>>>>>Example file
>>>>>---
>>>>>WEBVTT
>>>>>Region: id=region1 width=50% lines=3 regionanchor=0%,100%
>>>>>viewportanchor=0%,100%
>>>>>Region: id=region2 width=30% lines=1 regionanchor=0%,0%
>>>>>viewportanchor=5%,5%
>>>>>
>>>>>Cue 1
>>>>>0:00:03.040 --> 0:00:15.302 region:region1 align:left
>>>>>So, I just wanted to introduce you to W3C,
>>>>>
>>>>>Cue 2
>>>>>0:00:06.920 --> 0:00:15.302 region:region1 align:left
>>>>>and to do so, I have some exciting information:
>>>>>
>>>>>Cue 3
>>>>>0:00:10.000 --> 0:00:15.302 region:region1
>>>>>W3C has been acquired by Twitter.
>>>>>
>>>>>Cue 4
>>>>>0:00:13.800 --> 0:00:15.302 region:region2
>>>>>[AUDIENCE GIGGLES]
>>>>>---
>>>>>
>>>>>Rendered at time 15.300 as in the attached region_noscroll_cues.png .
>>>>>
>>>>>This has two regions that are both filled from the bottom line upwards
>>>>>(just like the previous case). The regions are fixed in size through
>>>>>the lines region setting. They are anchored so that if the font size
>>>>>changes, it's easy to see where the region and cues grow from. The
>>>>>first two lines in region1 are left aligned, the third is middle
>>>>>aligned within region1, the fourth is middle aligned within region2
>>>>>(middle alignment is default for cues). I could have used a "line"
>>>>>setting on the cues to determine which line within their region cues
>>>>>would be rendered into. In that way, I could have started rendering
>>>>>cues in the top line then successively fill the two lines below in
>>>>>region1 (that would be: line:-1, line:-2, line:-3 or line:2, line:1,
>>>>>line:0 just as before for cues without region except the numbering is
>>>>>applied within the region rather than the viewport).
>>>>>
>>>>>
>>>>>3. Cues in a named region that is scrolling:
>>>>>
>>>>>These are cues that are rendered into a rollup (scrolling) region.
>>>>>
>>>>>Example file
>>>>>---
>>>>>WEBVTT
>>>>>Region: id=region1 width=50% lines=3 regionanchor=0%,100%
>>>>>viewportanchor=0%,100% scroll=up
>>>>>Region: id=region2 width=30% lines=1 regionanchor=0%,0%
>>>>>viewportanchor=5%,5% scroll=up
>>>>>
>>>>>Cue 1
>>>>>0:00:03.040 --> 0:00:15.302 region:region1 align:left
>>>>>So, I just wanted to introduce you to W3C,
>>>>>
>>>>>Cue 2
>>>>>0:00:06.920 --> 0:00:15.302 region:region1 align:left
>>>>>and to do so, I have some exciting information:
>>>>>
>>>>>Cue 3
>>>>>0:00:10.000 --> 0:00:15.302 region:region1
>>>>>W3C has been acquired by Twitter.
>>>>>
>>>>>Cue 4
>>>>>0:00:13.800 --> 0:00:15.302 region:region2
>>>>>[AUDIENCE GIGGLES]
>>>>>---
>>>>>
>>>>>Rendered at time 9.000 as in the attached region_scroll_cues.png .
>>>>>
>>>>>This has two regions that are both allowing cues to be scrolled. The
>>>>>regions are fixed in size through the lines region setting, but are
>>>>>squashed to height 0 until cues are actually added. That can be seen
>>>>>easily in the picture for region2 (since it's at time 9.000). In
>>>>>region1, we have thus far rendered 2 cues. They are added one by one,
>>>>>starting in the bottom most line and moving "up". This is why cue 1 is
>>>>>in line 2 of region1 and cue 2 is in line 3.
>>>>>
>>>>>======
>>>>>
>>>>>While preparing these examples, I noticed that some contradict the way
>>>>>current regions are defined. In particular we need to change the
>>>>>following:
>>>>>* the spec currently says that cues in region are added one line at a
>>>>>time below existing cue lines -> this will need to be conditioned on
>>>>>the cue being in a scrolling region only
>>>>>* the spec currently prohibits "line" settings on cues in regions -
>>>>>this should be allowed for cues that are not in scrolling regions
>>>>>
>>>>>Once that is done, the rendering of non-scrolling regions and
>>>>>anonymous regions is identical with only scrolling regions having some
>>>>>special rules. That should make it easier to consolidate the rendering
>>>>>section. Have I overlooked any corner cases?
>>>>
>>>> What happens when the rendered cue text doesn't fit on a single line,
>>>>or
>>>> if wrapped to multiple lines occupies more lines than the region can
>>>> stretch to? Does the scrolling behaviour influence the output?
>>>
>>>Yes, if scrolling is enabled, the oldest line will scroll out of view.
>>>If no scrolling is enabled, it's possible that some lines of the newly
>>>rendered cue overflow and thus are not visible.
>>
>> If a single cue does not wholly fit within the region and scrolling is
>> enabled, so that there's no 'oldest' cue, will the implementation be
>> expected to make an attempt to show all of the lines in turn until all
>> have been displayed?
>
>The lines will scroll up one at a time, but if the region is
>restricted to 3 lines and the cue occupies 4, then the first line will
>disappear. I believe that would be the same in CEA-708, which was the
>model for how we defined regions.
>
>
>> Assuming 'yes' to this, are there timing constraints
>> to define the minimum visibility duration for each line prior to it
>>being
>> scrolled out of the visible area?
>
>Scrolling happens with a CSS transition whose duration is defined to
>be 0.433s, which is the value that CEA-708 prescribes. Is that what
>you're asking for?

I don't think so - sounds like this is the animation transition duration
for the scroll operation not the minimum duration of visibility of each
line when not being animated, which is what needs to be specified for
readability.

>>I mean in the WebVTT, globally or per
>> cue, rather than in the spec. The use case for this is to maintain a
>> maximum required reading rate (words per minute), which is likely to be
>> content dependent.
>
>Understood. This is a corner case of poor authoring, which I believe
>isn't taken care of in CEA708 either. Feel free to correct me or to
>suggest a different approach. What does TTML do in this case?

WebVTT is opening up new ground here, by allowing a region's dimensions to
be set without necessarily controlling the text size. TTML doesn't have
the same issue because all of the responsibility lies with the author. In
WebVTT client-side styling and rendering can change the presentation and
therefore create this somewhat over-constrained scenario, whilst also
potentially offering routes out of it that wouldn't be available in TTML.
In this case it's important to specify as friendly as possible a fallback
scenario.

Several fallback scenarios may exist, and I wouldn't like to be too
prescriptive when others may have better ideas. Some ideas (not
proposals!) may be:

- a 'shrink text to fit' setting that allows clients to resize or
re-layout text to fit on the specified number of lines;
- some combination of horizontal and/or vertical scrolling patterns that
allows the client to maintain a maximum word reading rate specified in the
document;
- limited ability for client to override region dimensions based on the
rato of client-specified font size to authored font size;
- ability to display some fallback text, specified in the document, in the
event that text is omitted, e.g. a pseudo-class ::nofit whose visibility
would typically set to 'visible' on inability to completely render and
'hidden' otherwise, and would thereby reveal text in a box, say "Some
caption text missing". Of course you'd have to find a way to ensure that
such text itself could be rendered!

Cheers,

Nigel


>
>Cheers,
>Silvia.



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-----------------------------

Received on Tuesday, 18 February 2014 12:01:41 UTC