💾 Archived View for bbs.geminispace.org › s › Geminispace › 17567 captured on 2024-06-16 at 19:35:10. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Re: "The Revolution Will Not Be In Proportional Width Font"
Unicode and UTF8 are pretty good bolt-on global solutions. However you never need to use 4 billion distinct glyphs. And rarely does one use more than a couple of different languages in a single document. In most cases, you could use 8-bit ASCII with the top 128 characters localized for your region. One would be enough for most European languages. In some cases like Japanese, just use 16 bits. This would be simpler and more compact. /
We had something like that, and people complained that you have to specify which code oage you are using. That is not hard, once per document! Instead we have to parse each character, which can be 1 to 4 bytes long, lose the ability to sort deterministically, can't tell the string length without parsing, and have look-alike glyphs that can be used by scammers.
In fact, UTF8 is a way to specify the code page every character!
Jun 01 · 2 weeks ago
Japanese has more than 5 ways to encode their characters.
Mojibake is what happens when encodings clash. (I saw it on DOS a lot)
— https://en.m.wikipedia.org/wiki/Mojibake
ASCII doesn't cover English, idéa isn't ASCII.
@MrSVCD: I could only think of 3... what are the 5?
@stack: from wikipedia: "There are several standard methods to encode Japanese characters for use on a computer, including JIS, Shift-JIS, EUC, and Unicode."
There are 5 versions of JIS, the first version worked easily on 8-bit computers.
@stack The top 128 might not be enough if you want to mix English, non-English and special characters - for example, if it's an algebra essay in Arabic, plus English letters and some special characters
@dimkr Yes for highly specialized tasks, a more complicated solution is worth it. But for the last week I've been saddled with annoying complexity putting together a simple Spanish quiz program. All I need is a handful of accented vowels and an Ñ. Now I have to use wide characters, causing a mismatch with stored data, or juggle UTF8 strings without being able to count bytes etc... Never thought I'd miss DOS.
TKurtBond, i was always wondering why in oberon system's text editors it is possible to use left and right arrow keys to navigate inside a line, but not possible to use up and down keys to change the line.
then i thought that maybe that's because in case of fonts with different width letters, there is this problem to solve, when if you go up, then down and you can find yourself in a different place, may occur, and wirth decided to avoid that problem.
@norayr: I've dealt with this issue on a few occasions. The solution is trivial to implement: maintain the target X position, and as the cursor moves up or down, go to the nearest available position.
Each vertical cursor navigation session keeps the target X, until horizontal movement, or some other X-altering event takes place.
Surely creators of languages and OSs are not stumped by such minor details...
The Revolution Will Not Be In Proportional Width Font — [gemini link] In the above link you will find what I believe to be a completely counterproductive and silly approach to thinking about terminals and ASCII. 1. List a set of problems in an unserious way. 2. Propose a vague solution (paraphrase: "something other than a terminal"). This approach to text will lead to the following behavior: Not taking the terminal seriously, and not solving problems for the terminal. Or, waiting for the...
💬 blah_blah_blah · 20 comments · 1 like · May 30 · 2 weeks ago