3 ms·
I don't disagree, but when you're an old-school developer it's hard to get this stuff right! I wrote a console-based mail client, and I struggled with UTF for
by stevekemp 10y ago
I don't disagree, but when you're an old-school developer it's hard to get this stuff right!
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 https://github.com/lumail/lumail2/issues/277
- chrisseaton 10y ago> 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/#combining-characters-and-character-width https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/#comb... > So the “length” of ... characters depends ... on the display font
- rspeer 10y agoWell, 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".
- ryandrake 10y agoAnd don't forget, it's not sum(glyph sizes) either. You ought to be taking into account kerning, too.