Le mercredi, 16 septembre 2015 à 21:27, Dominikus Dittes Scherkl a écrit : > Why adding them up? > I think every grapheme cluster of hangul syllables would have simply > width 2 - that is the concept of CJK charakters.
I don't personally know how CJK characters behave in general w.r.t. to width, that's why I'm asking. I'm just trying to find a simple, best-effort, data-driven algorithm for the problem at-hand by using standard properties and possibly without making built-in assumptions about scripts. Le mercredi, 16 septembre 2015 à 20:33, Richard Wordingham a écrit : > Have you addressed the issue of Indic scripts? There are > discontiguous grapheme clusters composed of indecomposable code points > (e.g. U+17C4 KHMER VOWEL SIGN OO) and of decomposable code points (e.g. > U+0BCA TAMIL VOWEL SIGN OO), Not sure I understand what you mean here. > and whether consonant + virama + consonant is one cell or two may even depend > on the font (e.g. > Devanagari). Well anything that is related to font metrics is out of scope from the point of view of a tty as I can't get the information. For example it seems that U+1F400 to U+1F579 have an east-asian width of N but will actually occupy two columns in the built-in osx terminal; of course these scalar values are not east asian text per se. > How are you handling ligatures between grapheme clusters, > e.g. English <f, i>? Here again I'd need font information for that, I expect the tty not to make ligatures between f and i. Of course the best way would be to be able to hand out a string to the tty for it to measure. But then it already seems impossible to test whether a terminal is able to handle UTF-8 or not… Maybe trying to use that east asian width property, was not a good idea to start with. Best, Daniel
