Re: Unifying the rendering approach

On Tue, Jan 28, 2014 at 1:35 PM, David Singer <singer@apple.com> wrote:
>
> On Jan 26, 2014, at 18:23 , Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>
>> On Fri, Jan 24, 2014 at 9:07 PM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
>>> The general problem with allowing the client to position cues that overlay
>>> other visual content, e.g. video,is that this does not take into account
>>> information that the viewer needs from that visual content itself. For
>>> example many hard of hearing users of captions need to see the mouths of
>>> people talking as well as the caption text. And some video content
>>> contains burnt-in text that is essential for understanding the programme.
>>> Traditionally this is managed by editorial effort to position the captions
>>> carefully at the authoring stage, at least in those formats that permit
>>> positioning data to be expressed.
>>
>> Right. So, the idea is that if the content was authored well, the
>> rendering in the browser will never have to deal with overlap
>> avoidance.
>>
>> However, not all content is authored well. For example content is
>> authored for a specific font size. If that font size is increased by
>> the user, or by a custom style sheet, the browser still should do its
>> best to render content in such a way that it's readable. If it can
>> move lines slightly and thus avoid overlap, surely that's preferable
>> to captions that overlay each other.
>
> It does seem that resolving these together is hard:
> * we prefer the cues to overlay the content because, even though they obscure part of the content, when they are there one doesn't need to change one's focus (move the eyes)

This is an authoring decision. If the author decides to avoid content,
he/she will position the cue elsewhere and we have to move our eyes
anyway.

> * we prefer to allow the user the option to override fonts, font sizes, colors, and other styles

What we're saying is that after all the authored content has been
placed as expected and all the user overrides have been taken into
account, if we then still have overlap and we can resolve it easily by
moving the text to a different line, we should do it. In the best
case, this should not create any different eye movements than the user
is already used to, because the text is just taking up a line more
than before (minus edge cases that we have to work out).


> I note, for example, it's possible for the user to over-ride the text and/or background colors so that the text is invisible in some cases.  ("I prefer blue text on a transparent background" -- until I watch a movie about skydiving, where the background is blue sky).
>
> I really don't like saying to the users "in *theory* what the source sends for styling are defaults that you can over-ride;  but, they are mandatory defaults, and if you over-ride them, some captions may be more visible bit some a lot less so", either.
>
> Nor do I like a system that is complicated by covering the cases of the few users who do, indeed, over-ride.  And indeed, testing one's content that 'reasonable' things happen when the users do over-rides is hard (well, there are multifarious possible over-rides).


Right. We are looking for a simple solution that gives up quickly if
it can't find a solution.

Silvia.

Received on Tuesday, 28 January 2014 08:25:57 UTC