text profile should support anamorphic fonts

[cconcolato]

Proper Japanese support requires being able to distinguish characters whose glyph look similar, by stretching some characters along the horizontal axis. For example, the following are very similar:

• Katakana-Hiragana Prolonged Sound Mark U+30FC
• Horizontal Bar U+2015

One can use "1.5em 1.0em" to make the "Horizontal Bar" appear longer and different from the "Prolonged Sound Mark". This is usually done in LambdaCap, which actually supports stretching factors of 2.0, 1.5, 0.9 or 0.5.

If hard to implement, maybe some restrictions could be applied, such as applicable to spans with only one character, or else.

[css-meeting-bot]

The Working Group just discussed text profile should support anamorphic fonts imsc#419, and agreed to the following:

• SUMMARY: @cconcolato to review and come back with further thoughts.

The full IRC log of that discussion

<nigel> Topic: text profile should support anamorphic fonts imsc#419
<nigel> github: https://github.com//issues/419
<nigel> Cyril: I raised this issue this morning.
<nigel> Nigel: I think this needs to go to requirements first, but we can discuss it here now.
<nigel> Cyril: Anamorphic fonts is a feature we use quite heavily. It is a de facto practice
<nigel> .. that was inherited from lambda cap. I suspect it is not easy to define two glyphs
<nigel> .. that are completely distinguishable within the em box, which may be why stretching
<nigel> .. is used instead of using specific fonts.
<nigel> Nigel: Is there any other way to achieve the result than to use fontSize with two components?
<nigel> Glenn: You mentioned two specific characters, distinguished by stretching. Practically
<nigel> .. speaking, just not stretching either of them and requiring the reader to use context
<nigel> .. to figure out which is which is not a horrible way to deal with this.
<nigel> Cyril: Our QC team clearly told me this is not acceptable.
<nigel> Glenn: Okay, I understand, though I think Japanese readers can fill in the blanks and
<nigel> .. distinguish them.
<nigel> Cyril: There's clearly ambiguity and we want to distinguish these cases.
<nigel> Glenn: It's a really high cost for what I consider really low value.
<nigel> Cyril: I understand that, which is why I suggested adding restrictions. I am open to any
<nigel> .. suggestions.
<nigel> Pierre: Before we go there, for the record, my interaction with folks other than Cyril
<nigel> .. who work with Japanese subtitles has been consistent with what I heard from Glenn.
<nigel> .. I think we need a separate meeting with interested parties to work out the solution.
<nigel> Cyril: Sure, I'm concerned about the timelines.
<nigel> Pierre: I do not think it can be implemented in CSS.
<nigel> Cyril: We can set up this meeting. I do not want to delay the process. What I can think
<nigel> .. of for today is to add the feature and mark it as at risk?
<nigel> Pierre: No, it is just not implementable in CSS. If you can point to a way it could be
<nigel> .. implemented that would address my concerns.
<nigel> Glenn: One of the things you mentioned is different glyphs. The implementation is free
<nigel> .. to map to whatever glyphs it wishes. One implementation approach would be to
<nigel> .. select different glyphs with intrinsically different widths. That would not require the
<nigel> .. general ability to specify an anamorphic font, which is a much costlier thing for
<nigel> .. implementation.
<nigel> Pierre: When I experimented with fonts, some of them showed a much bigger difference
<nigel> .. between those two characters than others. Like in some Latin fonts it can be hard to
<nigel> .. tell an O from a 0 or an l from a 1.
<nigel> Glenn: Yes that's exactly the point.
<nigel> Cyril: Okay I will come back to you on this issue but it might be a blocker for us to
<nigel> .. progress IMSC.
<nigel> Pierre: Understood.
<nigel> Glenn: In a sense I view this as a quality of implementation issue.
<nigel> Pierre: That's where I am but maybe there's more information to bring to the table that I don't know yet.
<nigel> Glenn: If this is the only example then anamorphic fonts is overkill.
<nigel> Cyril: It's not anamorphic fonts but the right restrictions to make it not overkill.
<nigel> Glenn: If you tweak the character then you're proposing a generic property that can
<nigel> .. apply to any character, not just the ones that have the problem. That's a more generic
<nigel> .. solution to this problem. You have to raise the cost vs gain comparison here.
<nigel> Nigel: I think looking for other ways to achieve an acceptable result is the way forward here.
<nigel> .. For example in SVG you could apply a transform, and maybe in CSS?
<nigel> Glenn: Only on block containers in CSS, not inlines.
<nigel> Cyril: If it is not used then why is it in LambdaCap?
<nigel> .. We ingest content with that feature in.
<nigel> Pierre: I'm guessing here, but one possibility is there's only one font that is used in
<nigel> .. LambdaCap. That could be a reason.
<nigel> Glenn: Actually LambdaCap has 6-10 font families that it can select.
<nigel> .. We implemented this in TTML2 with generic stretching. There is a pretty heavy toll
<nigel> .. on the implementation to support anamorphic fonts. For example you have to have
<nigel> .. anamorphic whitespace as well as anamorphic glyphs. There is a whole bunch of things
<nigel> .. that it affects.
<nigel> Cyril: Okay I'll come back to you on this one.
<nigel> SUMMARY: @cconcolato to review and come back with further thoughts.