ARIB liaison 2025-09-05: Table 1. Base Character Set

[palemieux]

Among the character sets listed in Table 1. Base Character Set, the characters listed in List 1. in this liaison
are not included in the character repertoire defined by ARIB STD-B62. ARIB Data WG understands that these characters are needed in some locales. However, from the perspective of ensuring commonality of IMSC around the world, the characters in List 1. in this liaison should be relocated to Table 2. Supplementary Character Sets in the FPWD.

List 1. Characters not included in ARIB STD-B62 among those listed in

Table 1 in Section B of the FPWD

U+0192 : LATIN SMALL LETTER F WITH HOOK
U+02DC : SMALL TILDE
U+2011 : NON-BREAKING HYPHEN
U+2012 : FIGURE DASH
U+2015 : HORIZONTAL BAR
U+2017 : DOUBLE LOW LINE
U+201A : SINGLE LOW-9 QUOTATION MARK
U+201E : DOUBLE LOW-9 QUOTATION MARK
U+201F : DOUBLE HIGH-REVERSED-9 QUOTATION MARK
U+2023 : TRIANGULAR BULLET
U+2024 : ONE DOT LEADER
U+2027 : HYPHENATION POINT
U+2031 : PER TEN THOUSAND SIGN
U+2034 : TRIPLE PRIME
U+2035 : REVERSED PRIME
U+2036 : REVERSED DOUBLE PRIME
U+2037 : REVERSED TRIPLE PRIME
U+2038 : CARET
U+2039 : SINGLE LEFT-POINTING ANGLE QUOTATION MARK
U+203A : SINGLE RIGHT-POINTING ANGLE QUOTATION MARK
U+2109 : DEGREES FAHRENHEIT
U+2120 : SERVICE MARK SIGN
U+2122 : TRADE MARK SIGN
U+2156 : VULGAR FRACTION TWO FIFTHS
U+2157 : VULGAR FRACTION THREE FIFTHS
U+2158 : VULGAR FRACTION FOUR FIFTHS

U+2159 : VULGAR FRACTION ONE SIXTH
U+215A : VULGAR FRACTION FIVE SIXTHS
U+215B : VULGAR FRACTION ONE EIGHTH
U+215C : VULGAR FRACTION THREE EIGHTHS
U+215D : VULGAR FRACTION FIVE EIGHTHS
U+215E : VULGAR FRACTION SEVEN EIGHTHS
U+215F : FRACTION NUMERATOR ONE
U+2588 : FULL BLOCK

[palemieux]

The Base Character Set is merely a recommendation: note the "should" instead of a "shall" in A document SHOULD be authored using characters selected from the sets specified in B. Common Character Sets at 8.1.

It is therefore acceptable for implementations to support a subset of the Base Character Set in particular circumstances.

The Base Character Set has been part of IMSC since the earliest edition and it would be surprising to remove characters, when the trend is to encourage implementations to support supporting as many Unicode characters as possible.

[css-meeting-bot]

The Timed Text Working Group just discussed ARIB liaison 2025-09-05: Table 1. Base Character Set w3c/imsc#616, and agreed to the following:

• SUMMARY: TTWG discussed 2025-09-11 and no proposal other than Won't Fix was made. A possibility was raised to add a ja-specific note.

The full IRC log of that discussion

<nigel> Subtopic: ARIB liaison 2025-09-05: Table 1. Base Character Set #616
<nigel> github: https://github.com//issues/616
<nigel> Pierre: My understanding of the issue is that IMSC recommends that authors use certain
<nigel> .. characters depending on language.
<nigel> .. There's a base set that can always be used, and all implementations should support it
<nigel> .. regardless of language.
<nigel> .. That base set has been in IMSC since time immemorial, and if I'm not mistaken it was derived
<nigel> .. from Blu-ray and home video titles.
<nigel> .. My understanding of the ARIB comment is that for their application the base set should not
<nigel> .. contain some characters, because they don't consider them as being universally needed.
<nigel> Cyril: Those that they suggest are not universal - I assume they're not Japanese?
<nigel> Pierre: They're things like horizontal bar, trademark sign, vulgar fraction 2/5, punctuation,
<nigel> .. graphic signs, service mark sign.
<nigel> .. I think some of those are not uncommon.
<nigel> .. My take on this is that's exactly why support for the base character set is a SHOULD not a SHALL
<nigel> .. specifically for that reason, that those characters are not necessarily completely universally
<nigel> .. applicable.
<nigel> .. My recommendation is that we do nothing and point out that it's a SHOULD and that in general
<nigel> .. people are encouraged to support as many Unicode characters as possible.
<nigel> .. Internationalisation was surprised we even had [sub]sets.
<nigel> Nigel: That makes sense to me.
<nigel> Pierre: I've labelled it as Won't Fix and provided a rationale.
<nigel> .. We should probably include that in our disposition in a liaison back to ARIB.
<nigel> Nigel: Any other views or comments?
<nigel> Cyril: You're suggesting Won't Fix. What would be the alternative, the next best solution?
<nigel> Pierre: The real issue is that this table, the base set, has been in IMSC forever.
<nigel> .. Trying to edit it partially would be a very significant undertaking and maybe pointless at the end.
<nigel> Cyril: I was thinking of other options. We could completely remove the base set.
<nigel> .. It's a SHOULD, if nobody implements it, what's the point?
<nigel> Pierre: It's been there for people who maybe don't know.
<nigel> .. Maybe things are different from in 2008 or 2012.
<nigel> .. If somebody creates a renderer and needs to know which characters amongst all of Unicode
<atsushi> q+ for agree with SHOULD, if we left as wontfix, we may need to weaken it somehow...
<nigel> .. they need to support, the base set plus language specific sets are a good place to start.
<nigel> .. If you're a specialist who knows better for local needs, then you can do what works for you.
<nigel> .. For a renderer on an embedded device it makes sense to use those tables to subset the
<nigel> .. characters supported, and those tables are incredibly useful.
<atai> q+
<nigel> Gary: There's already a note that it's not intended to limit processors from deciding what to render.
<nigel> Pierre: I think it was a reasonable compromise between "all of Unicode" and "what's in 608".
<nigel> q?
<nigel> ack ats
<Zakim> atsushi, you wanted to discuss agree with SHOULD, if we left as wontfix, we may need to weaken it somehow...
<nigel> Atsushi: Reading the spec strictly, instances should be using the character sets in Appendix B too,
<nigel> .. a SHOULD, and there's a note in B saying it's not intended to limit the set of possible characters
<nigel> .. the processor understands. Reading it strictly, it's a processor minimum (that SHOULD be supported)
<nigel> .. We first added to the ja table in 1.3 draft.
<nigel> .. There is inconsistency between ARIB 1 and what we have here.
<nigel> .. There may be inconsistency between the IMSC 1.3 definition and the ARIB one.
<nigel> s/ARIB 1/ARIB one
<nigel> .. I propose to add a note about the ja set that some characters could be omitted from the base
<nigel> .. set to weaken the minimum requirement for the processor for ja specifically.
<nigel> .. If not, there's an inconsistency at the SHOULD level compared to ARIB that could cause some
<nigel> .. issues in the future.
<nigel> q?
<nigel> ack atai
<nigel> Andreas: I don't have a strong view. Question: is there any indication that those base characters
<nigel> .. are actually used? Do we have feedback about which characters are used?
<nigel> .. Otherwise we could remove it because it is nearly impossible for us to review if the base set
<nigel> .. is the correct one.
<nigel> q?
<nigel> Pierre: I will quadruple check, but these characters came from the original member submission.
<nigel> .. [checks]
<nigel> .. Yes, that came from the initial member submission - it definitely had a character set.
<nigel> .. That was the result of actual study of home video material.
<nigel> .. And the intersection with 608 and 708.
<nigel> .. There's a basis for those tables, they're not random.
<nigel> .. Since then they've been updated.
<nigel> .. To the question of usage, unfortunately like all voluntary standards with no licensing we have
<nigel> .. no idea who uses IMSC. If the criteria depend on knowing about usage we would have no spec!
<nigel> .. I'm not excited to remove text that is only a recommendation.
<nigel> .. This would be a very different conversation if we were talking about convergence with ARIB
<nigel> .. and ultimately ARIB referencing IMSC and not ARIB-TT then it would be different.
<nigel> .. It would be reasonable at least to have a note. We might not want to create a ja set that
<nigel> .. conflicts with past ARIB-TT practice. As far as I can tell ARIB-TT will continue being a separate
<nigel> .. specification managed separately.
<nigel> .. So I do not want to impose additional constraints on IMSC at this time.
<nigel> Nigel: For a local usage it is reasonable to impose additional constraints on IMSC if they make
<nigel> .. sense. So an adopter could say "IMSC but with SHALL support for some specific set of characters"
<nigel> .. that they define, and that wouldn't be non-conformant with IMSC at all as it stands.
<nigel> .. I think that's an argument in favour of Won't Fix.
<nigel> Pierre: Again, it's not clear from the liaison but if ARIB is interested in discussing convergence
<nigel> .. this might be a different discussion.
<nigel> .. Maybe we ought to ask about that when we get back to ARIB.
<nigel> Nigel: Does anyone think Won't Fix is not what we should be doing here?
<nigel> .. Hearing nothing, that's the summary then.
<nigel> SUMMARY: TTWG discussed 2025-09-11 and no proposal other than Won't Fix was made. A possibility was raised to add a ja-specific note.