- From: Glenn Adams <glenn@skynav.com>
- Date: Thu, 20 Nov 2014 07:21:04 -0700
- To: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Cc: "Dewa, Yoshiharu (OSAKI)" <Yoshiharu.Dewa@jp.sony.com>, Michael Dolan <mdolan@newtbt.com>, TTWG <public-tt@w3.org>
- Message-ID: <CACQ=j+cJZhpvooZq2JEyReYzTo07gAOuomCooCQrzqso=E-kpA@mail.gmail.com>
On Thu, Nov 20, 2014 at 7:08 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote: > From: Glenn Adams <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> > 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> >> Date: Thursday, 20 November 2014 04:56 >> To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Glenn Adams <glenn@skynav.com> >> Cc: Michael Dolan <mdolan@newtbt.com>, TTWG <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 >> <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> >> *Date: *Monday, 17 November 2014 07:56 >> *To: *Glenn Adams <glenn@skynav.com> >> *Cc: *Michael Dolan <mdolan@newtbt.com>, TTWG <public-tt@w3.org> >> *Subject: *RE: ARIB-TT >> *Resent-From: *<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 <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> wrote: >> >> Hi Glenn, >> >> >> >> Followings are my understanding, so official translated specification is >> different from this. J >> >> >> >> 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] >> *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> 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] >> *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 <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 >> >> >> >> >> >> >
Received on Thursday, 20 November 2014 14:21:53 UTC