6 ms·

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.

vermilingua 5y ago
This is some schoolyard level stuff right here. The GP isn't using a monospaced font. Who, in the history of terminal emulators, has wanted to use a non-monospaced font in their terminal?
- onion2k 5y ago
  This is exactly the sort of "we can just skip that feature to make it faster!" edge case that I was talking about in my post.
  - vermilingua 5y ago
    But it isn't an edge case! It's not an edge case, if it isn't a use case! This is an edge case as much as building a rasterizer directly into the terminal is an "edge case".
    - l30n4da5 5y ago
      > But it isn't an edge case! It's not an edge case, if it isn't a use case! The fact that a random commenter on HN used a non-monospaced font with refterm actually makes it a use case. I do, however, agree that it is an edge case with a very low probability.
      - fouric 5y ago
        Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be". The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts. That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.
        l30n4da5 5y ago
        Agreed. It doesn't seem like it is relevant. My comment was more addressing that it _is_ an edge-case, albeit a very unlikely one.
  - maficious 5y ago
    Would you actually...?
  - 9935c101ab17a66 5y ago
    Wait, what? Your edge case is something that no one would ever (should ever?) do? Are you going to complain about it not rendering scripts fonts correctly either? Also, it's worth noting that this isn't a compelling argument in the first place because the windows terminal doesn't even come close to rendering readable Arabic, it fucks up emoji rendering, etc – all cases that Casey was able to basically solve after two weekends of working on this.
    - onion2k 5y ago
      In my 25 years of software development I've found that I'm rarely able to enumerate what an application should or shouldn't do on my own. Unless the app is extremely simple and has very few options it's incredibly unusual for any individual to understand everything about it. While I don't have a use case where I'd want to use a variable space font in a terminal, that doesn't mean such a case doesn't exist for anyone. Maybe some people want that feature. Windows Terminal, for some reason, gives users the option to change their font to one that isn't monospaced, so I'd argue that it should render them correctly if the user chooses to do that.
- avereveard 5y ago
  https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png so what now?
Aeolun 5y ago
As far as I understood from the video about refterm the speedup is mostly due to not rendering literally every frame in sequence (after all, who needs that), which is what windows terminal seems to be doing. That seems like it would be unaffected by correcting font rendering.
- maficious 5y ago
  > That seems like it would be unaffected by correcting font rendering. It is. "... extremely slow Unicode parsing with Uniscribe and extremely slow glyph generation with DirectWrite..." Glyph generation is about rasterising text, because you can't just feed it the font file.
maficious 5y ago
Refterm is a not a full-featured terminal in terms of configurability, but it has all the features needed for rendering. Configuration like: choosing fonts, choosing colors, tabs, whatever, it's misc. features, which are unrelated to rendering. The case here is about rendering and it's exactly what is shite in every terminal emulator. I don't understand why everyone is arguing about it anyway. Refterm provides a fix, Windows Terminal should simply implement it. Is this dignity or what? Are you not engineers? Should you not prioritise software quality above everything else? EDIT: Remove argument about ease of development, because refterm is easy. This bugs me every time. "Wow, this software works so good, but we are not gonna make our software like that, no, we'll stick to our shite implementation."
- makomk 5y ago
  The fact that Casey Muratori's proposed approach requires the terminal to reimplement the process of correctly mapping characters to glyphs - including stuff like fallbacks to other fonts - is a huge part of the argument for why it's much harder to implement and more complicated than he claims. If it really doesn't do that right for something as simple as a decimal seperator for the font some random HN commenter happened to use, that does tend to suggest the Microsoft employees are in the right here.
  - maficious 5y ago
    The "font some random HN commenter happened to use" is some f****** proportional Calibri. I want to see someone use it in any terminal emulator. Refterm defaults to Cascadia Code, but, fair enough, it doesn't have fallback yet. Its' description says also: "Reference monospace terminal renderer". "monospace" is there for a reason. It's worth mentioning though, that Windows Terminal also defaults to Cascadia Code and Cascadia Code was installed automatically on my machine, so it's de-facto the new monospace standard font on Windows starting from 10.
    - avereveard 5y ago
      > some f*** proportional Calibri Refterm defaults to Cascadia Code cascadia is as borken as the other font, so what now? https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png maybe writing a unicode rendering isn't that easy? maybe drop the attitude?
avereveard 5y ago
doesn't work even with the proper font https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png
- jiggawatts 5y ago
  You're not arguing in good faith. Casey threw something together in a matter of days that had 150% of the features of the Windows Terminal renderer, but none of the bug fixing that goes into shipping a production piece of software. That screenshot you keep parading around is a small issue with a quick fix. It's not like Casey's approach is inherently unable to deal with punctuation! You don't discard the entire content of a scientific journal paper because of a typo. "Sorry Mr Darwin, I'm sure you believe that your theory is very interesting, but you see here on page 34? You wrote 'punctuted'. I think you meant 'punctuated'. Submission rejected!"
  - makomk 5y ago
    In this case, the bug fixing is probably the lion's share of the work though - there's a huge amount of subtle edge cases involved in rendering text, and the Microsoft employees almost certainly know this. And the example that broke it isn't even something particularly obscure. We're literally talking about the output of the dir command, one of the first things someone is likely to do with a terminal window, not displaying correctly. He basically did the easy part of the work and lambasted some Microsoft employees as idiots because they thought it was more complex than that.
    - mwcampbell 5y ago
      In Casey's defense (I'm ambivalent on this one), while the dir command itself isn't obscure, one could argue that using a no-op Unicode character as the digit group separator is an obscure case, at least for an American programmer. But I think your overall point still stands.
  - avereveard 5y ago
    You've lost the original point: everyone was pretending this refterm was ready to replace the terminal app, criticizing microsoft for taking the slow but sure approach: > The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal! But now apparently pointing out that "MS was right not to want to take shortcut in unicode rendering" morphed into "criticizing in bad faith refterm for not being production ready" Who's not arguing in good faith here?

Does the GP's chosen font work correctly in Windows Terminal, though? If so, then that proves that there is indeed more to a fully functional terminal renderer than refterm covers.

vermilingua 5y ago

This is some schoolyard level stuff right here. The GP isn't using a monospaced font. Who, in the history of terminal emulators, has wanted to use a non-monospaced font in their terminal?

onion2k 5y ago
This is exactly the sort of "we can just skip that feature to make it faster!" edge case that I was talking about in my post.
- vermilingua 5y ago
  But it isn't an edge case! It's not an edge case, if it isn't a use case! This is an edge case as much as building a rasterizer directly into the terminal is an "edge case".
  - l30n4da5 5y ago
    > But it isn't an edge case! It's not an edge case, if it isn't a use case! The fact that a random commenter on HN used a non-monospaced font with refterm actually makes it a use case. I do, however, agree that it is an edge case with a very low probability.
    - fouric 5y ago
      Because it's such an improbable edge case, it seems like it's not relevant to the more general discussion of "does refterm's speed and features actually show that the rendering problem is far easier than the Microsoft developers made it out to be". The Microsoft terminal doesn't render monospaced fonts, the overwhelmingly common case, nearly as fast as refterm. If rendering variable-width fonts is somehow intrinsically insanely expensive for some reason (which I haven't seen anyone provide good evidence for), then a good implementation would still just take refterm's fast monospaced rendering implementation and use it for monospaced fonts, and a slower implementation for variable-width fonts. That is - refterm's non-existent variable-width font rendering capabilities do not excuse the Windows terminal's abysmal fixed-width font rendering capabilities.
      - l30n4da5 5y ago
        Agreed. It doesn't seem like it is relevant. My comment was more addressing that it _is_ an edge-case, albeit a very unlikely one.
- maficious 5y ago
  Would you actually...?
- 9935c101ab17a66 5y ago
  Wait, what? Your edge case is something that no one would ever (should ever?) do? Are you going to complain about it not rendering scripts fonts correctly either? Also, it's worth noting that this isn't a compelling argument in the first place because the windows terminal doesn't even come close to rendering readable Arabic, it fucks up emoji rendering, etc – all cases that Casey was able to basically solve after two weekends of working on this.
  - onion2k 5y ago
    In my 25 years of software development I've found that I'm rarely able to enumerate what an application should or shouldn't do on my own. Unless the app is extremely simple and has very few options it's incredibly unusual for any individual to understand everything about it. While I don't have a use case where I'd want to use a variable space font in a terminal, that doesn't mean such a case doesn't exist for anyone. Maybe some people want that feature. Windows Terminal, for some reason, gives users the option to change their font to one that isn't monospaced, so I'd argue that it should render them correctly if the user chooses to do that.
avereveard 5y ago
https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png so what now?

Aeolun 5y ago

As far as I understood from the video about refterm the speedup is mostly due to not rendering literally every frame in sequence (after all, who needs that), which is what windows terminal seems to be doing. That seems like it would be unaffected by correcting font rendering.

maficious 5y ago
> That seems like it would be unaffected by correcting font rendering. It is. "... extremely slow Unicode parsing with Uniscribe and extremely slow glyph generation with DirectWrite..." Glyph generation is about rasterising text, because you can't just feed it the font file.

maficious 5y ago

Refterm is a not a full-featured terminal in terms of configurability, but it has all the features needed for rendering. Configuration like: choosing fonts, choosing colors, tabs, whatever, it's misc. features, which are unrelated to rendering. The case here is about rendering and it's exactly what is shite in every terminal emulator. I don't understand why everyone is arguing about it anyway. Refterm provides a fix, Windows Terminal should simply implement it. Is this dignity or what? Are you not engineers? Should you not prioritise software quality above everything else? EDIT: Remove argument about ease of development, because refterm is easy. This bugs me every time. "Wow, this software works so good, but we are not gonna make our software like that, no, we'll stick to our shite implementation."

makomk 5y ago
The fact that Casey Muratori's proposed approach requires the terminal to reimplement the process of correctly mapping characters to glyphs - including stuff like fallbacks to other fonts - is a huge part of the argument for why it's much harder to implement and more complicated than he claims. If it really doesn't do that right for something as simple as a decimal seperator for the font some random HN commenter happened to use, that does tend to suggest the Microsoft employees are in the right here.
- maficious 5y ago
  The "font some random HN commenter happened to use" is some f****** proportional Calibri. I want to see someone use it in any terminal emulator. Refterm defaults to Cascadia Code, but, fair enough, it doesn't have fallback yet. Its' description says also: "Reference monospace terminal renderer". "monospace" is there for a reason. It's worth mentioning though, that Windows Terminal also defaults to Cascadia Code and Cascadia Code was installed automatically on my machine, so it's de-facto the new monospace standard font on Windows starting from 10.
  - avereveard 5y ago
    > some f*** proportional Calibri Refterm defaults to Cascadia Code cascadia is as borken as the other font, so what now? https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png maybe writing a unicode rendering isn't that easy? maybe drop the attitude?

avereveard 5y ago

doesn't work even with the proper font https://i.imgur.com/WeV8Ror.png https://i.imgur.com/WeV8Ror.png

jiggawatts 5y ago
You're not arguing in good faith. Casey threw something together in a matter of days that had 150% of the features of the Windows Terminal renderer, but none of the bug fixing that goes into shipping a production piece of software. That screenshot you keep parading around is a small issue with a quick fix. It's not like Casey's approach is inherently unable to deal with punctuation! You don't discard the entire content of a scientific journal paper because of a typo. "Sorry Mr Darwin, I'm sure you believe that your theory is very interesting, but you see here on page 34? You wrote 'punctuted'. I think you meant 'punctuated'. Submission rejected!"
- makomk 5y ago
  In this case, the bug fixing is probably the lion's share of the work though - there's a huge amount of subtle edge cases involved in rendering text, and the Microsoft employees almost certainly know this. And the example that broke it isn't even something particularly obscure. We're literally talking about the output of the dir command, one of the first things someone is likely to do with a terminal window, not displaying correctly. He basically did the easy part of the work and lambasted some Microsoft employees as idiots because they thought it was more complex than that.
  - mwcampbell 5y ago
    In Casey's defense (I'm ambivalent on this one), while the dir command itself isn't obscure, one could argue that using a no-op Unicode character as the digit group separator is an obscure case, at least for an American programmer. But I think your overall point still stands.
- avereveard 5y ago
  You've lost the original point: everyone was pretending this refterm was ready to replace the terminal app, criticizing microsoft for taking the slow but sure approach: > The "complaining developer" produced a proof of concept in just two weekends that notably had more features[1] and was more correct than the Windows Terminal! But now apparently pointing out that "MS was right not to want to take shortcut in unicode rendering" morphed into "criticizing in bad faith refterm for not being production ready" Who's not arguing in good faith here?