Re:UCS vs. UTF-8 as Internal String Encoding
by protomyth on Thursday May 28, 2015 @03:11PM
(#9620408)
I used 128-bit as a max. I just don't like some unbounded thing when we know that there is a practical max. I wouldn't call something perfectly fine when getting the number of characters actually displayed on the screen is a chore.
[ Parent
| on HN ]
What's wrong with unbounded? The amount of text you're rendering is unbounded (except by resource constraints). Combining diacritics are just another kind of text, that happen to lay out vertically rather than horizontally even in horizontal layout.
What do you mean by "getting the number of characters actually displayed on the screen"? Do you mean number of glyphs? Number of grapheme clusters? The number of glyphs is dependent on your text rendering system and fonts; even with plain ASCII, you may have multiple codepoints rendered as a single glyph, such as in ligatures like "ffi" in certain fonts. The number of grapheme clusters can be computed by the given algorithm along with some tables of character properties; it's not particularly simple, but trying to represent languages that were originally hand-written on a computer is not simple: http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
Re:UCS vs. UTF-8 as Internal String Encoding
by protomyth on Thursday May 28, 2015 @07:16PM
(#9621787)
The number of times I have to hit the backspace to delete a line of text.
Instead of backspace, shift+home, delete is a fast way to delete lines of any length.
Re:UCS vs. UTF-8 as Internal String Encoding
by TazeTSchnitzel on Friday May 29, 2015 @07:51AM
(#9623994)
That's application-dependant.