RE: Spec question on textOutline

RE: "The studios I know that use it for subtitles, set it dark, but not 100% black.  And, they always explicitly set it to control authorial intent, so initial values and tts:color settings don't come into play."

The non black is probably?  due to a lack of anti-aliasing / gradient  on the applied outline. JFYI we tend to apply a gradient across the outline (on both inner and outer edges) to alpha blend with the foreground text colour and the background video / region.

I agree that a change is probably more 'technically correct' than 'practically necessary', I.e. IMHO when outline is used, a colour is likely to be set (either in the document or externally).

Regards,
John


John Birch | Screen | Strategic Partnerships Manager
Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems

Visit us at
Broadcast Asia 2013, 18 - 21 June 2013, Marina Bay Sands, Singapore

P Before printing, think about the environment

From: Michael Dolan [mailto:mdolan@newtbt.com]
Sent: 27 April 2013 00:46
To: public-tt@w3.org
Subject: RE: Spec question on textOutline

I agree it is odd as defined and worthy of discussing a change more consistent with tts:color. I'm not sure it matters too much though.

The studios I know that use it for subtitles, set it dark, but not 100% black.  And, they always explicitly set it to control authorial intent, so initial values and tts:color settings don't come into play.

For user interface overrides of attributes in US closed caption applications, the decoder will have to be built such that when attribute values are user-set, it will ignore the ones in the document as well as initial values.

So, while technically more sensible/consistent to change it as you propose, I can't think of a use case where it would matter in practice. Did you have one in mind?

Also, do you agree with the permitted syntax constructions at the bottom?  It seems obvious to me now, but just a sanity check.  Thanks.

Regards,

                Mike

From: Sean Hayes [mailto:Sean.Hayes@microsoft.com]
Sent: Friday, April 26, 2013 1:15 PM
To: Michael Dolan; public-tt@w3.org<mailto:public-tt@w3.org>
Subject: RE: Spec question on textOutline

Yes, I think the text is not ambiguous; I guess I'm really questioning its usefulness. As John points out, at least in a captioning environment it's pretty uniformly set to black.  It would indeed be a breaking change so I would consider this a 1.1 issue; that is assuming we think its big enough to worry about.

Sean.


From: Michael Dolan [mailto:mdolan@newtbt.com]
Sent: 26 April 2013 17:07
To: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: RE: Spec question on textOutline

The spec is currently quite clear I think that it is the tts:color value (same as the font):

...if no color term is present, the computed value of the tts:color applies.

I see your point about it being locked to another color that is implementation dependent.  Are you proposing we adopt the tts:color language?

The initial value of the tts:color property is considered to be implementation dependent. In the absence of end-user preference information, a conformant presentation processor should use an initial value that is highly contrastive to the background color of the root container region.

I see the logic in that, but this change would be non-backwards compatible, though, which is unfortunate.

A bit eye-opening for me is the syntax interpretation that allows length but no color.  It never occurred to me that <length> without <color> was permitted, but indeed, the only required field is one length value.  This certainly makes the decoder parsing a lot more interesting than I thought. So, to be clear, the permitted constructions are:

<length>
<length> <length>
<color> <length>
<color> <length> <length>

Good thing color values have "#".

Regards,

                Mike

From: Sean Hayes [mailto:Sean.Hayes@microsoft.com]
Sent: Friday, April 26, 2013 5:59 AM
To: public-tt@w3.org<mailto:public-tt@w3.org>
Subject: Spec question on textOutline

A question from one of our developers who was asking what is the default color for a textOutline value that specifies two lengths, but no color value.

My reading of the specification text is that in this case the outline color takes the same value as the font color (which if not otherwise specified by the author, is implementation dependent). This seems to us somewhat less than useful in practice, and it might be better if the value in this case were chosen by the implementation so as to create a high level of contrast between the character and its background (e.g. black for a white character on a transparent background).

Not sure if anyone else has run into this? What do people think?

Sean.


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ