Re:A Programmer’s Introduction to Unicode
by chrisseaton on Saturday March 04, 2017 @01:02PM
(#13792048)
> rather than the length of the rendered string
Do unicode strings really have a rendered length?
https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/#comb...
> So the “length” of ... characters depends ... on the display font
Well, when you're writing a console program, you can assume your font is monospaced and you can assume you have a function like wcwidth() that will tell you how many monospaced cells a string will take up.
I know that eev.ee points out that wcwidth() is inconsistent (emoji screwed it up, then Unicode 9 gave a consistent width to emoji, but most libraries aren't on Unicode 9 so the situation is currently more inconsistent than before). But the situation is a lot better than just saying "I don't know, blame fonts".
I wrote a console-based mail client, and I struggled with UTF for months before it was all done, and even then there were niggles caused by libraries - for example passing a C++ string to a Lua script, and then using the `string:len()` lua function would return the number of bytes, rather than the length of the rendered string. Something I had to work around:
https://github.com/lumail/lumail2/issues/277