3 ms·

Also, in the 70s, you have a bitmap font of max 256 characters of equal size. Nowadays displaying text requires font selection, text shaping (incl. kerning), gl

Also, in the 70s, you have a bitmap font of max 256 characters of equal size. Nowadays displaying text requires font selection, text shaping (incl. kerning), glyph selection, text layouting (incl. line wrapping), glyph pre-rendering, and a final assembly step to get the composite image of all glyphs. Want to skip font selection? No emojis for you. Want to skip glyph selection? No ligatures or Arabic or Devanagari text for you. Want to skip text layouting? No Right-to-Left support for you. There is a whole crapton of legitimate complexity in the font rendering stack because we don't want to have the constraints of the 70s anymore (only 256 glyphs, fixed font size, monospace font only). (Sidenote: For those of you who think "I'm fine with monospace fonts in my terminal", I am using a monospace font as well. But "monospace font" only means that all ASCII glyphs are equal-sized, which is a tiny minority of all glyphs a Unicode font supports. I have grown a very strong opinion regarding this topic since I started to learn Japanese and hence want to be able to deal with CJK characters.)

selfhoster11 6y ago
Most terminal usage will be restricted to the English-language software and source code, for expediency reasons or because English is the lingua franca of tech. You can usually get away without RtL and ligature/wide glyph support. What I would like to see is a terminal that has a default high-performance monospace-only rendering engine, but gracefully and dynamically switches to a different rendering engine that supports the full-blown text layout capability once the terminal detects some input that makes use of these features.
- majewsky 6y ago
  You might be surprised how often you trigger that second code path. For just one example, an increasing number of CLI programs use emoji in their output, whether you like it or not.
  - selfhoster11 6y ago
    I'm actually a great fan of using emoji to spice up terminal output. Most of these would be fixed width too, isn't it? I know there are wide emoji, but most times I see them around one char wide.
    - majewsky 6y ago
      Emoji are square, which makes them overwide under most (all?) monospace fonts.

selfhoster11 6y ago

Most terminal usage will be restricted to the English-language software and source code, for expediency reasons or because English is the lingua franca of tech. You can usually get away without RtL and ligature/wide glyph support. What I would like to see is a terminal that has a default high-performance monospace-only rendering engine, but gracefully and dynamically switches to a different rendering engine that supports the full-blown text layout capability once the terminal detects some input that makes use of these features.

majewsky 6y ago
You might be surprised how often you trigger that second code path. For just one example, an increasing number of CLI programs use emoji in their output, whether you like it or not.
- selfhoster11 6y ago
  I'm actually a great fan of using emoji to spice up terminal output. Most of these would be fixed width too, isn't it? I know there are wide emoji, but most times I see them around one char wide.
  - majewsky 6y ago
    Emoji are square, which makes them overwide under most (all?) monospace fonts.