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