Re: [ttml2] Action-369 - collate smpte issues and draft dispositions

On Thu, Mar 5, 2015 at 1:35 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

>  From: Glenn Adams <glenn@skynav.com> Date: Wednesday, 4 March 2015 18:49
>
>
>  On Wed, Feb 25, 2015 at 8:22 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
>>  As discussed in our meeting of 2015-02-12, I've updated this draft
>> disposition as below, taking into account the guidance from that meeting
>> (minutes at http://www.w3.org/2015/02/12-tt-minutes.html). There are no
>> outstanding questions on the dispositions, though an editorial pass would
>> be a good idea before sending outside the TTWG.
>>
>>   NB the dispositions are intended to capture the sense of the
>> implementation state, with the intent that if that is captured correctly it
>> should be edited as needed prior to issuing as a formal communication.
>>
>>  Relating to the liaison at
>> https://lists.w3.org/Archives/Member/w3c-archive/2012Sep/0214.html – I
>> considered the previous requests concerning metadata to be out of scope of
>> this action.
>>
>>  *tts:disparity*
>> This is Issue-224
>>
>>  *Disposition:* Implementing using the tts:disparity style attribute
>> applicable to div, p and region, as a positive or negative length value
>> matching the requested semantics. Note that the animate element may be used
>> to continuously animate the value of this style attribute if required.
>>
>>  The applicability of disparity to div and p needs to be qualified to
> avoid confusion. In fact, it is not directly applicable to div or p, but is
> applicable to an anonymous inline region to be associated with the div or
> p. That is, specifying disparity on div or p behaves like specifying extent
> or origin on div or p, in that it triggers generation of an anonymous
> inline region to which these properties directly apply.
>
>
>  Yes, thanks for pointing that out – I suggest we simply remove the div
> and p references, as it's really only applicable to a region. I think the
> TTML2 spec could also use some non normative text describing the various
> (three by my count) ways to specify region placement also, perhaps in the
> Introduction section 1.2. Also I see that implied inline regions are
> omitted from the specification of region in 11.1.2, where I'd expect to see
> it, even if only to define the priorities of region creation if a content
> element has both origin/extent attributes and an explicit inline region.
>
>
>
>>
>>  *tts:fontSize as percentage of root container dimensions*
>> This is Issue-225 - CLOSED
>>
>>  *Disposition:* Implemented by adding vw and vh metrics to all values
>> whose syntax is specified as <length>, where vw is 1% of the width of the
>> root container region and vh is 1% of the height of the root container
>> region.
>>
>>
>>  *<p> origin and extent*
>> This is Issue-226 – CLOSED duplicate of Issue-176 – CLOSED.
>>
>>  *Disposition:* Implemented by permitting tts:origin and tts:extent to
>> be specified on <p> and <div> as a shorthand for specifying an inline
>> region.
>>
>>  s/inline region/anonymous inline region/
>
>
>  I think you mean "implied inline region"?
>

maybe; but the phrase anonymous inline region is also used


>
>
>>
>>  *<p> fade-up and –down*
>> - apply tts:opacity to <p>
>> This is Issue-227 - CLOSED
>>
>>  *Disposition:* Implemented: tts:opacity style attribute now applies to
>> body, div, p, region and span, and the animate element may be applied for
>> specifying continuous (as opposed to discrete) changes to styling
>> attributes including opacity.
>>
>>
>>  *Ruby text*
>> - position before or after
>> - offset –1.0 em to +infinity
>> This is Issue-228 - CLOSED
>>
>>  *Disposition:* Implemented within constraints of Ruby Annotations
>> http://www.w3.org/TR/2001/REC-ruby-20010531/#abstract-def using new
>> syntax, i.e. by introducing ruby attributes on <span> elements, not by
>> introducing <ruby>, <rt>, <rb> etc elements as per HTML5.
>>
>>  The positions permitted are before, after and around. The offset is not
>> constrained.
>>
>
>  Might be useful to explicitly cite the new tts:rubyPosition and
> tts:rubyOffset properties. Note also the tts:rubyAlign property which
> wasn't explicitly asked for by SMPTE (AFAICT), but which is commonly
> required in practice.
>
>
>  Okay – then s/ruby attributes/the ruby attributes tts:rubyAlign,
> tts:rubyOffset and tts:rubyPosition/
>
>
>
>>
>>
>>  *Mixed vertical-horizontal progression direction*
>> This is Issue-357 – CLOSED duplicate of Issue-229 – CLOSED.
>>
>>  *Disposition:* Implemented using tts:textCombine style attribute based
>> on semantics on CSS Writing Modes §9.1. This allows horizontal text in a
>> <span> to be inserted into vertical writing mode text so that the combined
>> glyph areas fit in the em square of the surrounding vertical text. If the
>> desired effect is to extend beyond a single em square, the applicable font
>> size
>>
>>  or line height
>>
>>  in the surrounding area can be increased to make the em square bigger
>> in the context of the horizontal group.
>>
>>  The latter is not entirely accurate (or specified as such). At present,
> the spec require the UA to fit the horizontal content into an EM square,
> which matches CSS's lack of specificity. Therefore, it is UA dependent as
> specified as to whether and how much scaling might be automatically applied.
>
>  In practice, I suspect it would be useful to have one or more additional
> properties that allow the author to give guidance to the UA on how to do
> this.
>
>
>  So would this work in place of the last sentence:
>
>  If the desired effect is to extend beyond a single em square,
> presentation processors can apply scaling to the em square for example to
> match the font size or line height, however this behaviour is currently
> unspecified.
>

change to "can apply scaling to the horizontal content to obtain a fit,
however ..."


>
>
>
>>
>>
>>  *Forced display*
>> This is Issue-230 - CLOSED
>>
>>  *Disposition:* Implemented using the condition attribute and a bound
>> parameter named 'forced' - this allows the value of for example the style
>> attribute tts:visibility to be conditionally set to "visible" or "hidden"
>> on style elements which can then be applied to the text that is
>> 'non-forced' to determine whether or not it should be rendered.
>>
>>
>>  *Individual character rotation*
>> This is Issue-229 - CLOSED
>>
>>  *Disposition:* Implemented using the tts:textOrientation style
>> attribute that can be applied to a <span>.
>>
>>   It might be useful to point out that only a small set of discrete
> orientations are supported at present, and inquire whether arbitrary
> rotation is required or not.
>
>
>  This done in my subsequent update relating to Issue-231.
>
>
>>
>>  *Bottom-to-top text direction*
>> This is Issue-232 - CLOSED
>>
>>  *Disposition:* Not implemented – marked as 'won't fix'. We have not
>> identified a use case for this. If there is a use case please tell us what
>> it is. Also note that there is no support for bottom to top writing mode in
>> CSS so a mapping into HTML/CSS may not be possible for this feature.
>>
>>
>>  *Superscript and subscript character style*
>> - baseline vertically offset by –0.5em or +0.5em
>> - fontsize 0.6em
>>
>>  This is Issue-233 – CLOSED duplicate of Issue-24 – CLOSED.
>>
>>  *Disposition:* Implemented using the tts:fontVariantPosition style
>> attribute with values normal/sub/super and semantics based on CSS Fonts
>> §6.5. Note that the requested behaviour of baselines offset by +0.5em or
>> –0.5em and a font size of 0.6em is not required by this solution, but may
>> be acceptable in some implementations. However it would be preferable to
>> avoid offsetting the baseline and use the superscript and subscript variant
>> glyphs in the font where available, or where not available, to use the
>> subscript and superscript fallback metrics specified within the font t's
>> OS/2 table. fontVariationPosition does apply cumulatively to nested <span>s.
>>
>>   Note that we expect to rename and generalize tts:fontVariantPosition
> to tts:fontVariant.
>
>
>  We should generally disclaim that this is a work in progress and details
> may change – the current snapshot has tts:fontVariantPosition so we should
> keep it.
>
>
>
>>
>>
>>  *Drop shadow character style*
>> - diagonally below and to the right
>> - specify color
>> - specify thickness in em
>>
>>  This is Issue-234 - CLOSED
>>  *Disposition:* Implemented using the tts:textShadow style attribute,
>> based on the semantics of CSS Text Decoration Module Level 3 §4 text-shadow
>> property.
>>
>>
>>  *Feathering of shadow and outline effects*
>>
>>  This is Issue-235 - CLOSED
>>  *Disposition:*  Implemented using the tts:textShadow style attribute,
>> based on the semantics of CSS Text Decoration Module Level 3 §4 text-shadow
>> property.
>>
>>
>>  *Character spacing, i.e. Letter-spacing with a span in units of em from
>> –1em to +infinity*
>> Inline space –1em to +infinity
>>
>>  This is Issue-236 duplicated as Issue-354 - CLOSED
>>  *Disposition:* Implemented using the tts:letterSpacing style attribute,
>> based on the semantics of CSS Text Module Level 3 §8.2 letter-spacing
>> property.
>>
>>  [end of requests]
>>
>>
>>
>