Korean text is not rendered properly about terminal

[lhecker]

I think Terminal is correct here.

It used to be correct! But nowadays, terminals are supposed to mostly handle grapheme clusters as per UAX#29 correctly (the Unicode Text Segmentation standard). The width of a glyph is the maximum width of each character in a grapheme cluster as per UAX#11 (the East Asian Width standard).

The two glyphs are syllable type L (leading consonant) and V (vowel), as per:

• https://codepoints.net/U+1105?lang=en
• https://codepoints.net/U+1173?lang=en

UAX#29 specifies that L×V do not break apart, which means that Windows Terminal has at least 1 bug: It should treat 르 as a single unit for cursor navigation, etc.

I'm not entirely sure whether ᄅ​ᅳ should be drawn as 르, because I'm not a native Korean speaker. But given the above it should definitely only get allocated 1 cell, which would mean that it should be drawn as 르, because it won't fit otherwise. I believe the only reason it currently gets drawn as ᄅ​ᅳ is because we rely on DirectWrite whose builtin support for modern Unicode is still incomplete. For instance, you can try pasting 르 into Word and it'll be broken just like it is in Windows Terminal. Both are built on top of DirectWrite. 😕

[lhecker]

Found the answer: https://devblogs.microsoft.com/oldnewthing/20201009-00/?p=104351
tl;dr: Windows (DirectWrite) does it ""right"" but they're literally the only one to do so, which is why Windows is effectively wrong. There's no alternative to DirectWrite though... Hmm, I hope I can figure something out because normalizing the input text to NFC first would be super awkward and make performance optimizations difficult.

[leejy12]

I think Terminal is correct here. The text file you provided contains two letters ᄅ(U+1105) and ᅳ(U+1173).
The browser seems to be combining those two together to render them as 르(U+B974), which I don't think should be happening.