Earlier quoted context omitted.
I'm sure that books can be printed in your language without any need for semantic information in the characters.
How do you Ctrl+F in a printed book? Why printed when we're taking about digital?
The Elegance of the ASCII Table
181–189 of 189 posts
Re: The Elegance of the ASCII Table
#182Re: The Elegance of the ASCII Table
#183Earlier quoted context omitted.
"Ą" is a separate letter in polish alfabet, not an accented variant of "A". There are writing systems where combining accents are used to represent just variation on a letter. Use of combining characters for "Ą" (and "Ć" and "Ł" and many other so-called "polish letters") is, at best, a historical artefact of trying to write them in deficient encodings.
It doesn't matter that it's a separate letter in an alphabet, you're denying the obvious - it IS an accented (or ogonek'ed) variant of A, and you can achieve this in Unicode in 2 ways: having one id for a precomposed variant and composing the variant from two ids. There is no semantic difference, just an encoding one, the end result looks the same and means the same thing (well, to a point, it still depends on the co…
Re: The Elegance of the ASCII Table
#184Earlier quoted context omitted.
> Unfortunately unfruitful. Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.
>widespread use We are talking about the early 80s at worst. It would have consolidated by now.
Re: The Elegance of the ASCII Table
#185Re: The Elegance of the ASCII Table
#186Earlier quoted context omitted.
>widespread use We are talking about the early 80s at worst. It would have consolidated by now.
I'm not sure I'm following. We have had multiple line endings (based on combinations of two particular characters) in common use, without consolidating to a common standard, for decades -- why would introducing a third character have made that more likely?
If a code had been timely assigned, we'd have the correct way (predominant), and the legacy ways (mostly gone by now).
Re: The Elegance of the ASCII Table
#187Earlier quoted context omitted.
Yes, that’s very intentional and just masking (or setting) the bit is the intended way to do case-insensitive comparison of the letter range in ASCII (eg. stricmp in C), or to transform text to lower or upper case (tolower, toupper). But what’s more, ever wondered whence the control (Ctrl) key presses like Ctrl-H to backspace, or Ctrl-M for carriage return? Well, inspecting the ASCII chart it becomes evident: the Ctr…
...it's a bit of a shame that the same upper/lowercase trick doesn't apply to all UNICODE codepoints (at least those that have upper/lower variants). It seems to work for codepoints up to U+00FF, for instance: - Å (U+00C5) vs å (U+00E5) ...but above 0xFF lowercase follows uppercase: - Ă (U+0102) vs ă (U+0103) Typical for UNICODE though, nothing makes sense ;)
Lowercase "I" could very well be "ı" (lowercase dotless i) if you're typing Turkish.
Re: The Elegance of the ASCII Table
#188Earlier quoted context omitted.
> For everyone else, UTF is a blessing. Except people who want to use Japanese and not have it render weirdly, something that was easy in any internationalised software that used the traditional codepage system, but is practically impossible in Unicode-based software.
How is it impossible if you Unicode has language tags?
Re: The Elegance of the ASCII Table
#189One downside of ASCII is the lack of two extra “letters” (whatever they might be, e.g. perhaps German ß), as it makes it impossible to represent base 64 alphanumerically. So we ended up with many alternatives picking two arbitrary punctuation marks.
base64 was proposed in 1987 to work with ASCII, EBCDIC, and other character encodings.