6 ms·

Indeed, GNU Unifont looks awful to many people, and even we only talk about bitmap fonts, Unifont is not the best-looking one. However, it's a font designed for

Indeed, GNU Unifont looks awful to many people, and even we only talk about bitmap fonts, Unifont is not the best-looking one. However, it's a font designed for practicability, not aesthetics. It's one of those few fonts that covers the entire Basic Multilingual Plane, and is actively maintained. It's a perfect choice as a fallback font. And in fact, the font actually looks pretty good under a CLI console. I once tried a Linux kernel patch that embedded the 10 MiB+ Unifont to the native Linux VT console, and I got a perfect multilingual console (without using a 3rd-party framebuffer-based or KMS-based console), including all the CJK characters. It's also a good choice for a dot-matrix LCD/LED display.

jfk13 8y ago
> I got a perfect multilingual console No, you didn't. If it was using Unifont, there are many scripts and languages that it was unable to display correctly because they require "shaping" that Unifont cannot support; it lacks the necessary glyphs, let alone the OpenType (or equivalent) tables to control the rendering. Displaying one nominal glyph per Unicode character does not result in readable text for many languages. Just because it seems adequate for Western alphabets or for CJK doesn't mean it is sufficient for true multilingual support.
- packet_nerd 8y ago
  To add to this, here's a few example complex text layout languages in no particular order: Thai, Khmer, Arabic, Hindi, Hebrew, Burmese, Tibetan, Punjabi, Sanskrit, and many many others. Many millions (billions?) of people won't be able to use your terminal in their language.
  - irrational 8y ago
    Also ancient language like Egyptian Hieroglyphics.
- usrusr 8y ago
  > Displaying one nominal glyph per Unicode character does not result in readable text for many languages Completely unreadable, even to people with a basic understanding of the inner workings of Unicode and some practice with the font, or just not matching the norms of correctness? Decipherable but clearly not correct would mark the sweet spot between being just as bad as placeholders and being so good that it undermines efforts for having a proper font for a given language.
  - jfk13 8y ago
    The degree of badness varies among languages/scripts. In some cases, yes, most readers would be able to decipher the intended content. In others, no, it really would be unreadable, except to those geeky enough to also comfortably "decipher" things like \x74\x68\x69\x73. Would you be happy routinely reading your terminal text in that form?
    - yorwba 8y ago
      > it really would be unreadable, except to those geeky enough to also comfortably "decipher" things like \x74\x68\x69\x73 Can you give an example?
      - jfk13 8y ago
        Try something in Devanagari script such as "क्षत्रिय" and see how it looks with Unifont. The results may vary, depending whether some kind of shaping engine (like Uniscribe, Pango, HarfBuzz, etc) gets involved in the process, but I'm confident it will be far from correct, and most readers would struggle to recognise it.
        mmastrac 8y ago
        I think your example can be illustrated by adding spaces between the characters like so: क्षत्रिय vs क् ष त्रि य (note how the first "glyph" decomposed into two drastically different characters)
chronogram 8y ago
Can you share the patch please? That sounds so useful!
JdeBP 8y ago
I use GNU Unifont, with a user-space virtual terminal. Some of GNU Unifont has looked far from "pretty good". I overlay K16-1990, 9x15, and Ubuntu Monospace on top of it for better-appearing characters. * http://jdebp.uk./Softwares/nosh/user-vt-screenshots.html#Unicode http://jdebp.uk./Softwares/nosh/user-vt-screenshots.html#Uni... * http://jdebp.uk./Softwares/nosh/guide/terminal-resources.html#fonts http://jdebp.uk./Softwares/nosh/guide/terminal-resources.htm... Your multilingual console is really far from "perfect". Aside from the aesthetics of GNU Unifont, you do not have good multilingual input, which you have completely left out. You don't have an ISO/IEC 9995 common secondary group. You do not have CJKV input methods. You still have problems with modifier keys becoming stuck "on" because of VT switching races. * https://unix.stackexchange.com/a/494685/5132 https://unix.stackexchange.com/a/494685/5132 And you also still have ISO/IEC 2022 8-bit character set switching for messing things up. (-: * https://unix.stackexchange.com/a/506140/5132 https://unix.stackexchange.com/a/506140/5132
- AnIdiotOnTheNet 8y ago
  Because English is already well suited to it, is it incredibly ethnocentric of me to believe that instead of trying to shoehorn the complexities and eccentricities of existing written text into the digital medium we should have instead adapted the writing systems to the medium so they'd be simpler to both represent and input? Because every time I look at what it takes to properly support unicode I'm pretty damn thankful ASCII is more than sufficient to represent my language.
  - yorwba 8y ago
    It's not ethnocentric, it's programmer-centric. If you consider supporting Unicode hard, imagine the effort required to get everyone to learn a new writing system and transliterate all existing works into it. At least Unicode support only requires a handful of specialists to create the necessary tooling, rather than some global uprooting of existing traditions.
    - AnIdiotOnTheNet 8y ago
      I think you over estimate the cognitive effort required. Just look at how quickly emoji were adopted into every-day communication. Maybe you can't transliterate Shakespeare into emoji very effectively, but some meaning is lost just reading it in modern English anyway and we could reserve the more complex systems for this kind of preservation.
CodeArtisan 8y ago
>including all the CJK characters. Is there a version of GNU Unifont for Japanese kanji? I could not find any. A few Japanese kanji share the same code-point as Chinese characters despite not being the same. https://i.imgur.com/DYqJTvN.png https://i.imgur.com/DYqJTvN.png https://en.wikipedia.org/wiki/Han_unification https://en.wikipedia.org/wiki/Han_unification
msla 8y ago
> Indeed, GNU Unifont looks awful to many people, and even we only talk about bitmap fonts, Unifont is not the best-looking one. And this is subjective. I have used Unifont in xterms for years now, and it's very readable and unambiguous to me. So it's good to see it getting some positive notice. > It's also a good choice for a dot-matrix LCD/LED display. Only a high-resolution one.
schoen 8y ago
It looks like your "perfect multilingual console" here rubbed people the wrong way—the Arabic ligatures are a straightforward counterexample. You got something that's helpful for working in a multilingual environment if you don't intend to read text in other languages but only to refer to it or recognize what it is. So I'd say that in a few cases that don't involve reading and writing or typography, this is potentially more useful, but it's important to be able to draw the distinction! For example, it's helpful for being able to say "the Arabic name for the Arabic language is spelled ة-ي-ب-ر-ع-ل-ا, alif-lam-ayn-ray-baa-yaa-taa marbuta". But if you want to have an Arabic speaker read it as a word, it ought to be written "العربية" (RTL with ligatures). Your terminal environment is good for the former but not the latter.
- deleted 8y ago
  [deleted]

jfk13 8y ago

> I got a perfect multilingual console No, you didn't. If it was using Unifont, there are many scripts and languages that it was unable to display correctly because they require "shaping" that Unifont cannot support; it lacks the necessary glyphs, let alone the OpenType (or equivalent) tables to control the rendering. Displaying one nominal glyph per Unicode character does not result in readable text for many languages. Just because it seems adequate for Western alphabets or for CJK doesn't mean it is sufficient for true multilingual support.

packet_nerd 8y ago
To add to this, here's a few example complex text layout languages in no particular order: Thai, Khmer, Arabic, Hindi, Hebrew, Burmese, Tibetan, Punjabi, Sanskrit, and many many others. Many millions (billions?) of people won't be able to use your terminal in their language.
- irrational 8y ago
  Also ancient language like Egyptian Hieroglyphics.
usrusr 8y ago
> Displaying one nominal glyph per Unicode character does not result in readable text for many languages Completely unreadable, even to people with a basic understanding of the inner workings of Unicode and some practice with the font, or just not matching the norms of correctness? Decipherable but clearly not correct would mark the sweet spot between being just as bad as placeholders and being so good that it undermines efforts for having a proper font for a given language.
- jfk13 8y ago
  The degree of badness varies among languages/scripts. In some cases, yes, most readers would be able to decipher the intended content. In others, no, it really would be unreadable, except to those geeky enough to also comfortably "decipher" things like \x74\x68\x69\x73. Would you be happy routinely reading your terminal text in that form?
  - yorwba 8y ago
    > it really would be unreadable, except to those geeky enough to also comfortably "decipher" things like \x74\x68\x69\x73 Can you give an example?
    - jfk13 8y ago
      Try something in Devanagari script such as "क्षत्रिय" and see how it looks with Unifont. The results may vary, depending whether some kind of shaping engine (like Uniscribe, Pango, HarfBuzz, etc) gets involved in the process, but I'm confident it will be far from correct, and most readers would struggle to recognise it.
      - mmastrac 8y ago
        I think your example can be illustrated by adding spaces between the characters like so: क्षत्रिय vs क् ष त्रि य (note how the first "glyph" decomposed into two drastically different characters)

chronogram 8y ago

Can you share the patch please? That sounds so useful!

JdeBP 8y ago

I use GNU Unifont, with a user-space virtual terminal. Some of GNU Unifont has looked far from "pretty good". I overlay K16-1990, 9x15, and Ubuntu Monospace on top of it for better-appearing characters. * http://jdebp.uk./Softwares/nosh/user-vt-screenshots.html#Unicode http://jdebp.uk./Softwares/nosh/user-vt-screenshots.html#Uni... * http://jdebp.uk./Softwares/nosh/guide/terminal-resources.html#fonts http://jdebp.uk./Softwares/nosh/guide/terminal-resources.htm... Your multilingual console is really far from "perfect". Aside from the aesthetics of GNU Unifont, you do not have good multilingual input, which you have completely left out. You don't have an ISO/IEC 9995 common secondary group. You do not have CJKV input methods. You still have problems with modifier keys becoming stuck "on" because of VT switching races. * https://unix.stackexchange.com/a/494685/5132 https://unix.stackexchange.com/a/494685/5132 And you also still have ISO/IEC 2022 8-bit character set switching for messing things up. (-: * https://unix.stackexchange.com/a/506140/5132 https://unix.stackexchange.com/a/506140/5132

AnIdiotOnTheNet 8y ago
Because English is already well suited to it, is it incredibly ethnocentric of me to believe that instead of trying to shoehorn the complexities and eccentricities of existing written text into the digital medium we should have instead adapted the writing systems to the medium so they'd be simpler to both represent and input? Because every time I look at what it takes to properly support unicode I'm pretty damn thankful ASCII is more than sufficient to represent my language.
- yorwba 8y ago
  It's not ethnocentric, it's programmer-centric. If you consider supporting Unicode hard, imagine the effort required to get everyone to learn a new writing system and transliterate all existing works into it. At least Unicode support only requires a handful of specialists to create the necessary tooling, rather than some global uprooting of existing traditions.
  - AnIdiotOnTheNet 8y ago
    I think you over estimate the cognitive effort required. Just look at how quickly emoji were adopted into every-day communication. Maybe you can't transliterate Shakespeare into emoji very effectively, but some meaning is lost just reading it in modern English anyway and we could reserve the more complex systems for this kind of preservation.

CodeArtisan 8y ago

>including all the CJK characters. Is there a version of GNU Unifont for Japanese kanji? I could not find any. A few Japanese kanji share the same code-point as Chinese characters despite not being the same. https://i.imgur.com/DYqJTvN.png https://i.imgur.com/DYqJTvN.png https://en.wikipedia.org/wiki/Han_unification https://en.wikipedia.org/wiki/Han_unification

msla 8y ago

> Indeed, GNU Unifont looks awful to many people, and even we only talk about bitmap fonts, Unifont is not the best-looking one. And this is subjective. I have used Unifont in xterms for years now, and it's very readable and unambiguous to me. So it's good to see it getting some positive notice. > It's also a good choice for a dot-matrix LCD/LED display. Only a high-resolution one.

schoen 8y ago

It looks like your "perfect multilingual console" here rubbed people the wrong way—the Arabic ligatures are a straightforward counterexample. You got something that's helpful for working in a multilingual environment if you don't intend to read text in other languages but only to refer to it or recognize what it is. So I'd say that in a few cases that don't involve reading and writing or typography, this is potentially more useful, but it's important to be able to draw the distinction! For example, it's helpful for being able to say "the Arabic name for the Arabic language is spelled ة-ي-ب-ر-ع-ل-ا, alif-lam-ayn-ray-baa-yaa-taa marbuta". But if you want to have an Arabic speaker read it as a word, it ought to be written "العربية" (RTL with ligatures). Your terminal environment is good for the former but not the latter.

deleted 8y ago
[deleted]