[WR/ARIB] Compatibility with ARIB-TTML / 2. Font handling

[himorin]

Per: w3c/ttwg#116
Comment 3 (#545), 2

In Japanese language, Kanji is one of essential characters. More than 10,000 Kanji (repertoire) are standardized for Japanese broadcast environment. But still characters not listed in the standard are still required in some cases. In ARIB STD-B62 based environment, two approaches are prepared against such cases.

Ideographic Variation Selector (IVS)

Some required Kanji characters can be considered as variants of existing characters. IVS is the mechanism to identify and handle this case as defined in clause 16.6 of ISO/IEC 10646:2017 or Unicode Technical Standard #37. With the Moji_Joho collection, 19 cases are included in ARIB TR-B39 which is the operational guideline for ARIB STD-B62. It is required for ARIB STD-B62 compliant environment to handle IVS properly.

Gaiji

When a non-standardized Kanji character is needed, “Gaiji” that is to place a glyph image of such a character is the way to support it. Use of code points in Private Use Area. (PUA) for such characters is common approach to avoid duplicated character assignment. For this purpose, “arib-tt:font-face” element is defined to allow additional characters packed in different fonts. The font is supposed to be delivered on the fly with the TTML document. SVG and WOFF can be used as available font formats. The “unicode-range” attribute is also available in the element so that the characters included in the font can be easily handled by a TTML processor. This element can also be used to handle inline graphics by rendering the graphic encoded as a glyph image. It can be achieved by a combination of a glyph image and PUA assigned code value, and/or a use of GSUB in WOFF if a processor is capable to handle it properly.

[nigelmegitt]

This appears to match functionality in IMSC 1.2, though with different syntax. I'm not clear what action we might take. Possibly we could informatively write something, either in IMSC or a separate document such as a wiki page or a WG Note, describing this equivalence.

[himorin]

might be possible to put some informative note section with #544? (not sure about the policy to include or not in IMSC spec...)

[css-meeting-bot]

The Timed Text Working Group just discussed [WR/ARIB] Compatibility with ARIB-TTML / 2. Font handling imsc#547, and agreed to the following:

• SUMMARY: TTWG is interested to know more about the usage of these features, and would like to consider noting the functional overlap in a future version.

The full IRC log of that discussion

<nigel> Topic: [WR/ARIB] Compatibility with ARIB-TTML / 2. Font handling imsc#547
<nigel> github: https://github.com//issues/547
<nigel> Nigel: This relates a bit to the conversation we had about putting images into text via fonts.
<nigel> Cyril: It is not even a feature of IMSC 1.2. Even in IMSC 1.1 or earlier, if you have the right
<nigel> .. font, then you can do it.
<nigel> Nigel: I've always thought you can only do that if you have a contract effectively that
<nigel> .. links the document to the font.
<nigel> Cyril: You can have a closed environment out of band of the document that allows this to be done.
<nigel> Nigel: Ah yes, understood.
<nigel> Pierre: I think this is exactly what they have in mind, an environment with specified font
<nigel> .. requirements.
<nigel> Cyril: Even out of band, broadcasting a font alongside the IMSC document. You could get
<nigel> .. it for free that way, whilst still being outside the scope of IMSC.
<nigel> Nigel: I think they are saying that they have an arib-tt:font-face element that references
<nigel> .. a font delivered externally somehow.
<nigel> Cyril: They seem to link the ability to do IVS and Gaiji with this arib-tt:font-face element.
<nigel> .. Maybe in our response we should say that in a closed environment you don't need
<nigel> .. a font-face element to use IVS and Gaiji.
<nigel> .. We can ask them if they have considered that.
<nigel> Nigel: It seems that in ARIB-TT and IMSC 1.2 we have both arrived at a similar solution.
<nigel> Pierre: Yes, I agree that it looks like the same capabilities are present and we can ask for
<nigel> .. samples of how they use it.
<nigel> Atsushi: +1
<nigel> Nigel: Does anyone have a sense of whether we should add something to IMSC vNext,
<nigel> .. informatively, noting the similar functionality?
<nigel> .. More widely, is it useful in IMSC to talk about functional overlap with other profiles of TTML?
<nigel> Cyril: We already do, with SDP-US or EBU-TT-D.
<nigel> .. Speaking of scope, yes maybe it could be in scope in the next version to extend the lsit
<nigel> s/lsit/list
<nigel> .. of standards it matches or overlaps.
<nigel> Pierre: As soon as we have the details to get comfortable with that, absolutely.
<nigel> SUMMARY: TTWG is interested to know more about the usage of these features, and would like to consider noting the functional overlap in a future version.

[mikedo]

Here is what I was told:

1. Kanji (mainly for for proper nouns) for which there are no font codes defined and/or /glyphs available
2. Emoji
3. (not captions/subtitles) Emergency information graphic such as a map during a tsunami

They use both SVG and PNG.

In case they did not already provide this, here is a link to the ARIB TTML specification in English:
https://www.arib.or.jp/english/std_tr/broadcasting/std-b62.html
Part 3 in volume 1 is the TTML spec.