Earlier quoted context omitted.
Danish keyboards also require you to press '¨' first and then 'o' to produce 'ö'.
But do you really use ö much over ø?
No, but I do once in a while (very rarely) write a little in german that might use that character.
What every software developer must know about Unicode in 2023
371–380 of 572 posts
Re: What every software developer must know about Unicode in 2023
#372Earlier quoted context omitted.
Danish keyboards also require you to press '¨' first and then 'o' to produce 'ö'.
Do the danes not have the mechanism that is found on Finnish keyboard layouts, where pressing AltGr+Ö yields Ø and AltGr+Ä yields Æ, except in reverse?
For me that doesn't work on Windows. Those key combinations doesn't seem to do anything.
Re: What every software developer must know about Unicode in 2023
#373I tried to read the articles since it seemed interesting. After exactly 30 seconds trying it I had to leave the page. Impossible to read more than two sentences with all those pointer moving there - and for a folk with ADHD even more difficult. Sorry, but I couldn't make it :(
Use the reader mode. Or if you are under GNU/Linux, use Links/Lynx.
Re: What every software developer must know about Unicode in 2023
#374Earlier quoted context omitted.
> Or typing 'o' + '¨' to produce 'ö' but realizing you wanted to type 'ô', there just one backspace press would revert it to 'o' again and you could press '^' to get the 'ô'. This is a good example because in German I would expect 'o' + '¨' + to leave no character at all while in French I would expect 'e' + '`' + to leave the e behind because in my mind it was a typo. The rendering of brahmic- and arabic-derived scri…
But typing "ö" (e.g. swiss keyboard) and pressing delete & getting an o would be annoying af
I realize that the editor would be the system to keep track of how the character was entered for this to work. If you made the character from a single keypress it would only make sense that backspace also undid the entire character. Only if you created the character from multiple keypresses it would make sense to "undo" only part of it with backspace (at least until you move away from the character).
Re: What every software developer must know about Unicode in 2023
#375Earlier quoted context omitted.
> Or typing 'o' + '¨' to produce 'ö' but realizing you wanted to type 'ô', there just one backspace press would revert it to 'o' again and you could press '^' to get the 'ô'. This is a good example because in German I would expect 'o' + '¨' + to leave no character at all while in French I would expect 'e' + '`' + to leave the e behind because in my mind it was a typo. The rendering of brahmic- and arabic-derived scri…
In French, è is a single character issued by a single keypress on a French keyboard, like e, or +. (Note that A is shift+a). Why should it need two backspaces? If you press e+` well you have e`, not è.
I am assuming that means "on French keyboard", not "in French". I have a usa keyboard and live in Canada...Every now and then it thinks I'm typing French and keyboard indeed behaves in a way that some vowel plus some quotation mark indeed gives me some other character (that I don't need :)
Re: What every software developer must know about Unicode in 2023
#376Earlier quoted context omitted.
> And if you're looking at character properties, the article says you should be looking at multiple together, which is correct. I don't see where the article mentions Unicode character properties [1]. These properties are assigned to individual characters, not groups of characters or grapheme clusters. > Very rarely will you be implementing those algorithms. True, but character properties are frequently used, i.e. ev…
> These properties are assigned to individual characters, not groups of characters or grapheme clusters. But you need to deal with the whole cluster. You can't just look at the properties on a single combining character and know what to do with it. If the article's saying to iterate one cluster at a time, then if you're doing properties a direct consequence is that you should be looking at the properties of specific…
The Unicode Standard does not specify how character properties should be extracted from a grapheme cluster. Programming languages that define "character" to mean grapheme cluster (like Swift) need to establish their own ad-hoc rules.
As others have pointed out in this thread, the article is full of the authors own personal opinions. The author suggests iterating text as grapheme clusters, but fails to consider that this breaks tokenizers, e.g. a tokenizer for a comma-separated list [1] won't see the comma as "just a comma" if the value after it begins with a combining character.
Re: What every software developer must know about Unicode in 2023
#377Earlier quoted context omitted.
Thanks. Unfortunately both .isEmojiPresentation && .isEmoji leaves many emojis out, like red heart and many other.
Those aren't inherently emojis, the font just shows them as emojis, so you'd have to render the text.
Correct. `isEmojiPresentation` checks if, per the Unicode standard, this scalar should default to an emoji presentation.
Re: What every software developer must know about Unicode in 2023
#378Earlier quoted context omitted.
If you type "a", combine it with "´", then change your mind and hit backspace, you probably want to end up with "a" even through "á" was a thing "visually displayed as a single unit".
Most European keyboard layouts have it the other way around: first press a "dead key" for the diacritic mark and then the letter to apply it to. Where some layouts may require this method for some characters, another keyboard layout may have the same character on a dedicated key. The program receives the combined character as one unit, and does not need to be aware of different keyboard layouts.
> first press a "dead key" for the diacritic mark and then the letter to apply it to.
That being exactly the way “floating diacritics” in ISO 2022 (or properly one of its Latin encodings, T.51 = ISO 6937) work, amusingly. I wonder which came first. (Yes, I know that a` came first, the ASCII spec even says that this should give you an accented character IIRC. Or perhaps it was one of the other “don’t call it ASCII” specs—ISO 646? IA5?..)
Re: What every software developer must know about Unicode in 2023
#379There's one part of this document that I would push extremely hard against, and that's the notion that "extended grapheme clusters" are the one true, right way to think of characters in Unicode, and therefore any language that views the length in any other way is doing it wrong. The truth of the matter is that there are several different definitions of "character", depending on what you want to use it for. An extende…
There are libraries that help with iterating both code-points and grapheme clusters... - but are there any of them that can help decide what to do for example when pressing backspace given an input string and a cursor position? Or any other text editing behavior. This use-case-dependent behavior must have some "correct" behavior that is standardized somewhere? Like a way to query what should be treated like a single…
I'd argue that you must use grapheme clusters for text editing and cursor position, because here are popular characters (like ö you used as example) which can be either one or two codepoints depending on the normalization choice, but the difference is invisible to the user and should not matter to the user, so any editor should behave exactly the same for ö as U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) and ö as a sequence of U+006F (LATIN SMALL LETTER O) and U+0308 (COMBINING DIAERESIS).
Furthermore, you shouldn't assume that there is any relationship between how unicode constructs a combined character from codepoints with how that character is typed, even at the level of typing you're not typing unicode codepoints - they're just a technical standard representation of "text at rest", unicode codepoints do not define an input method. Depending on your language and device, a sequence of three or more keystrokes may be used to get a single codepoint, or a dedicated key on keyboard or a virtual button may spawn a combined character of multiple codepoints as a single unit; you definitely can't assume that the "last codepoint" corresponds to "last user action" even if you're writing a text editor - much of that can happen before your editor receives that input from e.g. OS keyboard layout code; your editor won't know whether I input that ö from a dedicated key, a 'chord' of 'o' key with a modifier, or a sequence of two keystrokes (and if so, whether 'o' was the first keystroke or the second, opposite of how the unicode codepoints are ordered).
Re: What every software developer must know about Unicode in 2023
#380Earlier quoted context omitted.
String iteration should be based on whatever you want to iterate on - bytes, codepoints, grapheme clusters, words or paragraphs. There's no reason to privilege any one of these, and Swift doesn't do this. "Length" is a meaningless query because of this, but you might want to default to whatever approximates width in a UI label, so that's grapheme clusters. Using codepoints mostly means you wish you were doing bytes.
> There's no reason to privilege any one of these, and Swift doesn't do this. Strange thing to say: Swift String count property is the count of extended grapheme clusters. The documentation is explicit: > A string is a collection of extended grapheme clusters , which approximate human-readable characters. [emphasis in original]
The length/count property was added after people asked for it, but it wasn't originally in the String revamp, and it provides iterators for all of the above. .count also only claims to be O(n) to discourage using it.