Re: Unifying the rendering approach

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? 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? 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.

>
>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 09:12:09 UTC