Re: [TTML2] font face (ISSUE-273)

> See CSS 2.1 [1] and CSS 3 Font Module [2] for examples. TTML1 already effectively references (via XSL-FO) the first of these. The latter improves on the former.
>
> [1] http://www.w3.org/TR/CSS21/fonts.html#algorithm

> [2] http://dev.w3.org/csswg/css-fonts/#font-matching-algorithm


Thanks. That looks pretty definitive - it would seem perverse for TTML2 not to use the same matching rules.


From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Thursday, 20 November 2014 14:21
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Cc: "Dewa, Yoshiharu (OSAKI)" <Yoshiharu.Dewa@jp.sony.com<mailto:Yoshiharu.Dewa@jp.sony.com>>, Michael Dolan <mdolan@newtbt.com<mailto:mdolan@newtbt.com>>, TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: [TTML2] font face (ISSUE-273)



On Thu, Nov 20, 2014 at 7:08 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Thursday, 20 November 2014 13:02

On Thu, Nov 20, 2014 at 2:17 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
Yoshiharu,

Thank you for this extra explanation.

Is there any restriction on the number of font-face elements with the same font-family name? If multiple font-faces with the same font-family are permitted, with overlapping unicode-range values, is there an algorithm for determining the correct one to use?

Firstly, note that we already have the case where multiple potential fonts apply, since tts:fontFamily expresses a prioritized list of families.

Secondly, regardless of what is done by ARIB, the approach I am drafting for TTML explicitly does not have such a restriction, and, indeed, requires support for selecting among multiple fonts sharing the same family name where other characteristics may differ, particularly character ranges. In such a case, for a given run of text that shares the same family, style, and weight, it may require sub-runs over that text where each sub-run maps to a different font resource, e.g., due to different ranges being supported.

The general font selection algorithm is as follows:

  1.  for a run of text that shares the same font family, style, and weight, compute an ordered list of font resources that "map" to these parameters (family, style, weight), taking into account fallback cases as required;
  2.  sub-divide this run such that each sub-run maps to the highest priority single font resource in this ordered list, where the font resource can map (to a glyph) each character in the sub-run, and where the sub-run's length is maximized;

With this algorithm, if there are multiple font resources that can map the same character (to a glyph), then a sub-run terminates when a higher priority font resource is available than the font resource initially selected for the sub-run.

So, for example, if one has run of "ABCDE", and the following character mapping support:

F1 - maps A, B, C, D, E
F2 - maps C, D

and priority F2 > F1

then one would get the following sub-runs:

"AB" : F1
"CD" : F2
"E : F1

If necessary, we could define a fontSelectionStrategy style property that selects between stop-sub-run-on-higher-priority or maximize-sub-run-length. The above example shows use of the stop-sub-run-on-higher-priority, while the maximize-sub-run-length strategy would yield:

"ABCDE" : F1

Note that there already is a font-selection-strategy property in XSL-FO [1], which has two values:

  *   auto (default)
  *   character-by-character

The 'stop-sub-run-on-higher-priority' approach above effectively corresponds to the character-by-character strategy, while the 'maximize-sub-run-length' approach is one possible (and commonly implemented) interpretation of the auto strategy.

[1] http://www.w3.org/TR/xsl/#font-selection-strategy


Thanks for the forward view of your thinking Glenn. As an individual member of the group, at this time I'm happy with this general approach, i.e. permitting multiple font faces for a given font family, building sub-runs etc. I don't have a strong view on which font selection strategy should be used so "auto" seems like a good starting point in the absence of more specific requirements.

As well as the algorithm for building sub-runs the prioritisation semantics need to be defined, i.e. how to do the prioritisation when there are new dimensions involved like unicode range, font weight and font style, additional to the ordered list.

My question was more targeted at discovering if there's existing work to define that prioritisation.

See CSS 2.1 [1] and CSS 3 Font Module [2] for examples. TTML1 already effectively references (via XSL-FO) the first of these. The latter improves on the former.

[1] http://www.w3.org/TR/CSS21/fonts.html#algorithm

[2] http://dev.w3.org/csswg/css-fonts/#font-matching-algorithm






From: <Dewa>, "Yoshiharu (OSAKI)" <Yoshiharu.Dewa@jp.sony.com<mailto:Yoshiharu.Dewa@jp.sony.com>>
Date: Thursday, 20 November 2014 04:56
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>, Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Cc: Michael Dolan <mdolan@newtbt.com<mailto:mdolan@newtbt.com>>, TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: RE: [TTML2] font face (ISSUE-273)

Nigel,

Ok. I'll try to explain ARIB-TT font-face element definition.

- arib-tt:font-face element is for specifying non-embedded font which can be used for "gaiji (external character)". The styling element on ARIB-TTML document can deploy one or more arib-tt:font-face element optionally.

arib-tt:font-face :
   font-family : Mandatory attribute for non-embedded font. tts:fontFamily attribute in other element can refer this font-family name.
   unicode-range : the range of corresponding font. The examples are as follows;
     - unicode-range ="U+A5" ; specific character to be applied example
     - unicode-range ="U+0-7F" ; specifying one range example
     - unicode-range ="U+A5 , "U+0-7F, …." ; specifying multiple range example
   arib-tt:src : parent element for specifying url attribute and format attribute. One or more src elements shall be specified.
     url : Mandatory attribute for font file location URL.
     format : font file format. "svg" or "woff" shall be specified.

Syntax:

<xsd:element name="font-face" type="arib:font-faceType"/>

<xsd:complexType name="font-faceType">
   <xsd:sequence>
      <xsd:element name="src" type="arib:font-face-srcType"
            maxOccurs="unbounded"/>
   </xsd:sequence>
   <xsd:attribute name="font-family" type="xsd:string" use="required"/>
   <xsd:attribute name="unicode-range” type="xsd:string"/>
   <xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>

<xsd:complexType name="font-face-srcType">
   <xsd:attribute name="url" type="xsd:anyURI" use="required"/>
   <xsd:attribute name="format" type="xsd:string"/>
   <xsd:attribute name="id" type="xsd:ID"/>
</xsd:complexType>


I found no explicit explanation for id attribute for font-face and src… though.

Rgs,
-- Yoshiharu


From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: Tuesday, November 18, 2014 11:39 PM
To: Dewa, Yoshiharu (OSAKI); Glenn Adams
Cc: Michael Dolan; TTWG
Subject: [TTML2] font face (ISSUE-273)

For information, and with permission, I have added the XSD section for font-face to the change proposal wiki page at https://www.w3.org/wiki/TTML/changeProposal015#font_face_rule as well as an alternate proposal being discussed in EBU. This relates to our tracker issue-273 at https://www.w3.org/AudioVideo/TT/tracker/issues/273


There appears to be a strong semantic alignment between the proposals though not a syntactic one.

Both proposals include in common  the semantic concepts of a font family name, a unicode range, and a set of sources.
ARIB-TT additionally permits an xml:id attribute on both the font-face and the source (src child element).
EBU proposal also permits matching based on font weight and font style, with an algorithm for selecting which source to use in case of multiple matches.

Apologies I am unable to translate the accompanying prose from ARIB-TT for English speakers, or indeed any of the prose into other languages for non-English speakers. Therefore I do not claim to have understood the ARIB-TT proposal for font-face in full.

Kind regards,

Nigel


From: <Dewa>, "Yoshiharu (OSAKI)" <Yoshiharu.Dewa@jp.sony.com<mailto:Yoshiharu.Dewa@jp.sony.com>>
Date: Monday, 17 November 2014 07:56
To: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Cc: Michael Dolan <mdolan@newtbt.com<mailto:mdolan@newtbt.com>>, TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: RE: ARIB-TT
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Monday, 17 November 2014 07:57

Hi Glenn,

Ok. I'm happy to support this.

Rgs,
-- Yoshiharu

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Monday, November 17, 2014 4:50 PM
To: Dewa, Yoshiharu (OSAKI)
Cc: Michael Dolan; TTWG
Subject: Re: ARIB-TT

Thanks. Would you like issues to be raised on TTML2 that requests support for this functionality?

On Mon, Nov 17, 2014 at 2:11 PM, Dewa, Yoshiharu (OSAKI) <Yoshiharu.Dewa@jp.sony.com<mailto:Yoshiharu.Dewa@jp.sony.com>> wrote:
Hi Glenn,

Followings are my understanding, so official translated specification is different from this. ☺

The arib-tt:letterspacing is an attribute that specify default letter spacing pixel units between letters.

Values:

<integer> value expression that use px (pixel) units

Initial:

default

Applies to:

style, body<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#document-structure-vocabulary-body>, div<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-vocabulary-div>, p<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-vocabulary-p>,  span<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-vocabulary-span>

Inherited:

yes

Percentages:

N/A

Animatable:

discrete




Syntax:

<xsd:attribute name="letter-spacing" type="xsd:string"/>



The arib-tt:marquee attribute specify element auto scrolling function. This attribute defines style, direction, speed and loop count can be specified.
When the element that is arib-tt:marquee attribute specified includes figures/images, these figures/images also scroll together.


Values:

<string> value expression that separated by white space

Initial:

No

Applies to:

style, body<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#document-structure-vocabulary-body>, div<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-vocabulary-div>, p<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-vocabulary-p>, span<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#content-vocabulary-span>

Inherited:

Yes

Percentages:

N/A

Animatable:

discrete? (not sure), continuous


Syntax:

<xsd:attribute name="marquee" type="xsd:string"/>

The marquee parameter is string that is separated by white space. The parameters are composed four parts
<marquee-style>,  <marquee-direction>, <marquee-speed> and <marquee-play-count>
(Ex. arib-tt:marquee=” scroll forward normal 1”)

<marquee-style>: specifies scroll style as follows;
scroll : from start position to end position, context of element shall be scrolled completely. At end position, context of the element is disappeared.
slide : The context of the element is slide in from start position and scroll until shows completely, then stopped.
alternate : from start position to end position context of element shall be scrolled completely. After showing completely, direction will be reversed and scroll again. (endless)

<marquee-direction> specifies scroll direction as follows;
forward：from left to right (for horizontal writing mode) or from top to bottom (for vertical writing mode)
reverse：from right to left (for horizontal writing mode) or from bottom to top (for vertical writing mode)

<marquee-speed> specifies scroll speed as follows
slow
normal
fast

Actual speed is specified by operational specification for each services.

<marquee-play-count> specifies scroll loop count. The integer value or infinite can be specified.

Rgs,
-- Yoshiharu


From: Glenn Adams [mailto:glenn@skynav.com<mailto:glenn@skynav.com>]
Sent: Monday, November 17, 2014 12:53 PM
To: Dewa, Yoshiharu (OSAKI)
Cc: Michael Dolan; TTWG
Subject: Re: ARIB-TT

Yoshiharu-san,

Thanks for your email explaining the ARIB-TT extensions, which I understand are based on supporting features in legacy Videotron Lambda and other (?) formats.

As we move forward with TTML2, it would be useful to obtain further input on, for example, whether new TTML2 features could interoperate (at least at the semantic, if not syntactic level) with the ARIB-TT features. For example, we have already drafted specification text for supporting:

  *   border [1]
  *   continuous animation [2]
  *   ruby (ルビ) [3][4][5][6]
  *   tate chu yoko (縦中横) [7]
We are also planning to support author supplied fonts (i.e., font-face), text shadow (in addition to the current text outline support), and have requests on file to support audio. Thus far, however, we don't have proposals to support letter spacing or marquee functions. It would be useful to learn if ARIB would wish to have TTML2 support these latter two functions (letter spacing and marquee) as well.

Regards,
Glenn Adams

[1] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-border

[2] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#animation-vocabulary-animate

[3] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-ruby

[4] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-rubyAlign

[5] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-rubyOffset

[6] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-showBackground

[7] https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#style-attribute-textOrientation





On Mon, Nov 17, 2014 at 8:23 AM, Dewa, Yoshiharu (OSAKI) <Yoshiharu.Dewa@jp.sony.com<mailto:Yoshiharu.Dewa@jp.sony.com>> wrote:
Hi,

There are nine extensions for arib-tt name space. It is derived from legacy Japanese subtitle system.

arib-tt:font-face : Extended for Gaiji (External character) feature using svg/woff font file

arib-tt:keyframes : Changing various style according to keyframe element

arib-tt:audio : play receiver's embedded sound or cli sound file in subtitle stream

arib-tt:animation : Define animation timing and style for arib-tt:keyframes

arib-tt:border : syntax sugar for border setting. (style, width, color)

arib-tt:letter-spacing : letter spacing specified by pixel value

arib-tt:marquee : marquee function

arib-tt:ruby : text ruby (much simplified W3C ruby spec…)

arib-tt:text-shadow : text shadow setting offset X/Y and blur radius and color


Hope this helps,

-- Yoshiharu

From: Michael Dolan [mailto:mdolan@newtbt.com<mailto:mdolan@newtbt.com>]
Sent: Saturday, November 15, 2014 8:33 AM
To: 'TTWG'
Subject: RE: ARIB-TT

I asked a Japanese TV colleague last week.  I was told that it’s currently authorized for UHDTV OTA and is planned for OTT. I’m trying to learn more and see if they want to get their extensions added to TTML/IMSC…

                Mike

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Friday, November 14, 2014 3:28 PM
To: TTWG
Subject: ARIB-TT

I've recently been apprised of the work by ARIB on extensions to TTML via ARIB-TT, pages number 57 and following in [1].

We should try to learn more about who is doing this work and interface with them regarding a number of extensions they have defined (in an ARIB defined namespace).

[1] http://www.arib.or.jp/english/html/overview/doc/2-STD-B62v1_0-1p2.pdf