5 ms·

This illustrates just how complex even the "basic" stuff turns out to be in practice. Text rendering hates you[1]. Even if you take obvious shortcuts/compromise

This illustrates just how complex even the "basic" stuff turns out to be in practice. Text rendering hates you[1]. Even if you take obvious shortcuts/compromises like limiting yourself to monospace, you'll get bitten by "double width" characters. Kudos to those who try, rather than bundling a copy of Chrome with their chat app. [1]: https://faultlore.com/blah/text-hates-you/ https://faultlore.com/blah/text-hates-you/

anthk 3y ago
Yeah, that's why ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough with just a small extended western table. Optional as a library, OFC. By default you write ASCII chars from a table with a "display" device. I prefer uxn's simplicity over my own complex locales. Anyway, as I said, a tiny .tal code for extended chars wouldn't be very big. Some fonts for uxn (look at the ~rabbit repos at git.sr.ht) already bring extended chars.
- rollcat 3y ago
  > [...] ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough [...] Making a bespoke ASCII extension would be a step back - by about 30 years. You don't need a lot of code to support UTF8; if you're concerned about runtime memory usage, you can make your rune type take 8 bits and support only the U+0000-00FF range[1]. It happens to cover all of [áéíóüñ] and a whole bunch of other languages - unfortunately, not my native one, which would leave me gravely upset ;P [1]: https://www.unicode.org/charts/PDF/U0080.pdf https://www.unicode.org/charts/PDF/U0080.pdf
  - zzo38computer 3y ago
    Then you could just implement ISO-8859-1 instead. It is the same range but a simpler encoding, and external programs could be used for conversion if necessary.
    - rollcat 3y ago
      1. UTF8 encoding is trivial and everything already speaks it by default nowadays; 2. it is useful to explicitly differentiate byte arrays from text; 3. if you'd change your mind later on and decide you do want to support Japanese (like here: https://100r.co/site/niju.html https://100r.co/site/niju.html), you haven't dug yourself into a hole.
      - anthk 3y ago
        The problem it's uxn it's ported to tons of devices. Would utf8 work under platforms like the Nintendo DS or DOS with a simple header file?
        tonyg 3y ago
        Should do! All the detail would be inside uxn, and the whole idea is that uxn virtualizes away from the underlying environment.
        rollcat 3y ago
        UTF8 is an extremely simple and lightweight text encoding. Check out Plan 9's man page on UTF, it would fit on a t-shirt: https://plan9.io/magic/man2html/6/utf https://plan9.io/magic/man2html/6/utf Unicode is also just a representation for text, and a handful of common operations - you work with arrays of characters, rather than arrays of bytes. It was worth its cost on 1992 hardware; Nintendo DS is over a decade more recent. I recommend studying libutf in sbase[0]. It's not a single header file solution (although utf.h[1] is an excellent place to start reading), but it does provide a fairly comprehensive implementation. There's also a good introduction to Unicode in Plan 9's C programming guide[2]. Even if you choose to only support runes that fit in a single byte, you gain the ability to tell byte blobs apart from text, which is useful both for reasoning about your program, and for future-proofing it, in case you needed to put places like Łódź or Πάτρα on your map. [0]: http://git.suckless.org/sbase http://git.suckless.org/sbase [1]: http://git.suckless.org/sbase/file/utf.h.html http://git.suckless.org/sbase/file/utf.h.html [2]: https://plan9.io/sys/doc/comp.html https://plan9.io/sys/doc/comp.html
      - 3y ago
zzo38computer 3y ago
I tried to tell other people that (and more; there are even more problems with Unicode than mentioned in that article) but they don't believe me and they believe that Unicode is good anyways. I design my own programs and specifications to avoid Unicode as much as possible, even when multilingual text (sometimes even in languages that Unicode does not have) is desirable.

anthk 3y ago

Yeah, that's why ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough with just a small extended western table. Optional as a library, OFC. By default you write ASCII chars from a table with a "display" device. I prefer uxn's simplicity over my own complex locales. Anyway, as I said, a tiny .tal code for extended chars wouldn't be very big. Some fonts for uxn (look at the ~rabbit repos at git.sr.ht) already bring extended chars.

rollcat 3y ago
> [...] ASCII with a few of accenter chars and glyphs [áéíóüñ] would be enough [...] Making a bespoke ASCII extension would be a step back - by about 30 years. You don't need a lot of code to support UTF8; if you're concerned about runtime memory usage, you can make your rune type take 8 bits and support only the U+0000-00FF range[1]. It happens to cover all of [áéíóüñ] and a whole bunch of other languages - unfortunately, not my native one, which would leave me gravely upset ;P [1]: https://www.unicode.org/charts/PDF/U0080.pdf https://www.unicode.org/charts/PDF/U0080.pdf
- zzo38computer 3y ago
  Then you could just implement ISO-8859-1 instead. It is the same range but a simpler encoding, and external programs could be used for conversion if necessary.
  - rollcat 3y ago
    1. UTF8 encoding is trivial and everything already speaks it by default nowadays; 2. it is useful to explicitly differentiate byte arrays from text; 3. if you'd change your mind later on and decide you do want to support Japanese (like here: https://100r.co/site/niju.html https://100r.co/site/niju.html), you haven't dug yourself into a hole.
    - anthk 3y ago
      The problem it's uxn it's ported to tons of devices. Would utf8 work under platforms like the Nintendo DS or DOS with a simple header file?
      - tonyg 3y ago
        Should do! All the detail would be inside uxn, and the whole idea is that uxn virtualizes away from the underlying environment.
      - rollcat 3y ago
        UTF8 is an extremely simple and lightweight text encoding. Check out Plan 9's man page on UTF, it would fit on a t-shirt: https://plan9.io/magic/man2html/6/utf https://plan9.io/magic/man2html/6/utf Unicode is also just a representation for text, and a handful of common operations - you work with arrays of characters, rather than arrays of bytes. It was worth its cost on 1992 hardware; Nintendo DS is over a decade more recent. I recommend studying libutf in sbase[0]. It's not a single header file solution (although utf.h[1] is an excellent place to start reading), but it does provide a fairly comprehensive implementation. There's also a good introduction to Unicode in Plan 9's C programming guide[2]. Even if you choose to only support runes that fit in a single byte, you gain the ability to tell byte blobs apart from text, which is useful both for reasoning about your program, and for future-proofing it, in case you needed to put places like Łódź or Πάτρα on your map. [0]: http://git.suckless.org/sbase http://git.suckless.org/sbase [1]: http://git.suckless.org/sbase/file/utf.h.html http://git.suckless.org/sbase/file/utf.h.html [2]: https://plan9.io/sys/doc/comp.html https://plan9.io/sys/doc/comp.html
    - 3y ago

zzo38computer 3y ago

I tried to tell other people that (and more; there are even more problems with Unicode than mentioned in that article) but they don't believe me and they believe that Unicode is good anyways. I design my own programs and specifications to avoid Unicode as much as possible, even when multilingual text (sometimes even in languages that Unicode does not have) is desirable.