💾 Archived View for bbs.geminispace.org › u › dimkr › 17512 captured on 2024-06-20 at 11:58:44. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-06-16)
-=-=-=-=-=-=-
Re: "The Revolution Will Not Be In Proportional Width Font"
The terminal is not very democratic if your native language is written right to left and has letters that don't fit in a single 'column' (incompatible with the idea of a monospace font)
May 31 · 3 weeks ago
👽 TKurtBond · May 31 at 16:33:
The Oberon System devevoped by Niklaus Wirth used a text based graphical user interface (supporting multiple fonts) that allowed the the user to add menus simply by opening another text file and entering the commands they wanted on that menu, which could then be executed directly using the mouse, with input to the command indicated in several standard ways. It used proportional fonts for everything, and was nothing like the common terminal. Later versions of the Oberon system supported text with embedded active components. The Oberon system is really amazing for everything it packs in such a simple package. The user interface is alien to the common conventions we are used to, but easy once accustomed.
🖥️ zetamacs · May 31 at 16:35:
@stack And they should. There is no good or principled reason to avoid it outside of programming for devices for which Unicode isn't an option, if you ask me.
I'm surprised there has still been no mention of Plan 9's reimagining of the terminal. Full Unicode support, ability to run a command and immediately block without scrolling so you don't need a pager, text can be freely edited anywhere it appears, "hold" mode for multi-line composition... in short, it's not an improved VT100-style terminal, it's something newer that's actually designed to work with a graphical display.
That's not as far as one could reasonably go, either.
@dimkr the solution for wide characters is double with like GNU Unifont does. It common in Japan, China and others.
— https://unifoundry.com/unifont/index.html
Some random thoughts
Going past ASCII does make everything an order of magnitude more complicated. Sorting order. Is a character capitalized? How long is a string? Simple bit tests are now calls to huge libraries, and things like sorting have no obvious solutions...
It's assumed for some reason, that one _has_to_ cater to every language, nationality, and gender, or be labeled 'fascist' or worse. If you are a huge corporation with unlimited resources and a desire to take over the world, OK.
If you are a person or a small group, I think it is perfectly reasonable to make a choice to limit the language support to a subset of the world. No disrespect is inherent in saying you will only support ASCII. Unless followed by a racist statement.
Although unless you really care about not linking any libraries (like I do in extremely minimal projects), adding at least superficial Unicode support is usually not a big commitment.
Are there really no terminals with good support for Arabic or Japanese? I find that hard to believe.
terminal resembles a typewriter. or actully teletype: tty.
what was printed once, can't be changed.
wirth designed oberon system to be text based, but it doesn't have terminals.
you can write a command (name of the object file and then after the dot name of its public function) anywhere. then click on it, and os will load the object file if necessary and execute the function.
ui can be text based, but not resemble a terminal.
@norayr: yes, the oberon interface is pretty amazing. I found out the hard way that I hate Oberon the language, though...
@MrSVCD I'm not an expert but I'm not sure if increasing width is a universal solution because some languages (like Arabic) have special cases specific sequences of letters become a single sign with width >=1, while most letters still have width 1
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!
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 · 3 weeks ago