W3C home > Mailing lists > Public > public-tt@w3.org > March 2015

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

From: Glenn Adams <glenn@skynav.com>
Date: Wed, 4 Mar 2015 11:49:59 -0700
Message-ID: <CACQ=j+f6f792Sbz2BNuL4d7KaodP2CxC3Tmvq4kXh+zFsP2Phg@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: Timed Text Working Group <public-tt@w3.org>
On Wed, Feb 25, 2015 at 8:22 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>

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

>  *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/

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

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

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

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

>  *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]
Received on Wednesday, 4 March 2015 18:50:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:43:46 UTC