Post by @gaditb@icosahedron.website

2026-07-28 00:37 UTC

... and open-ended follow-up question: In this context: Projects in the... retrocomputing? computational-demake? alt/green-tech? a-particular-subset-of-permacomputing? category, like #uxn or #CollapseOS / #DuskOS -- what options to they have towards non-Latin alphabets? Is "either no non-Latin, or else full Unicode" likewise inevitable? Is there something different they are or could do that could lead to some other option (e.g. different per-language/script versions of their software)? etc.?

Replies (2)

@kepstin@tenforward.social 2026-07-28 00:59

@gaditb@icosahedron.website the primary thing that would matter here is memory and storage capacity. If you have sufficient memory and storage, then have at it - use unicode and unicode fonts, and provide multiple localizations within a single app build. If you have extremely limited memory and storage, then it's very important to limit the character set to be as small as possible, often to the point where character drawing can be done entirely in hardware using bitmap font where glyphs are indexed directly from the character set. Applications will have to be separately built for each locale, will not support data transfer across locales, and some locales will have to work around the fact that the full set of glyphs needed for their language aren't available. For example, 8-bit computers and early computer connected printers in Japan could often only display/print the https://en.wikipedia.org/wiki/JIS_X_0201 character set, which was more or less ascii plus half-width katakana. You didn't get hiragana or Kanji until high-resolution graphics became possible. As another example, early pokemon games on the gameboy used 8-bit character codes and a sprite sheet with around 240 characters, covering uppercase-only latin letters, numbers, some punctuation, hiragana, katakana, and a very small number of kanji.

Open ##5319899
@u2764@icosahedron.website 2026-07-28 04:05

@gaditb@icosahedron.website the question imo is in terms of usecase keeping text in a custom encoding is very possible, and translating between encodings is very possible, especially if you allow “convert from encoding A to Unicode and convert from Unicode to encoding B” because then each encoding only needs to define Unicode mappings to be fully interchangeable (in fact i have developed some software for precisely this) but if your usecases include large amounts of multilingual text, then you probably need to support Unicode, or at least aren’t saving much by not using Unicode, at least as far as the encoding format goes (whether you buy into the full set of algorithms is another question)

Open ##5319900