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