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.
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."
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.
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.
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?
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!"
I haven't changed anything, just downloaded and launched, that's the result. if the term only works with one font why is the software picking a random one from the system conf?
It looks like refterm is hard-coded to use Cascadia Mono, which isn't included in-box with Windows 10. So I don't know what happens if you don't have that font. If that's the only issue, then I think we can let that one go, as refterm is clearly only a proof of concept, and one-time logic for choosing the correct font at startup would presumably have no effect on rendering speed.
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.
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."
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.
13 replies →
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.
> 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.
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?
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.
7 replies →
https://i.imgur.com/WeV8Ror.png so what now?
doesn't work even with the proper font https://i.imgur.com/WeV8Ror.png
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!"
7 replies →
I haven't changed anything, just downloaded and launched, that's the result. if the term only works with one font why is the software picking a random one from the system conf?
It looks like refterm is hard-coded to use Cascadia Mono, which isn't included in-box with Windows 10. So I don't know what happens if you don't have that font. If that's the only issue, then I think we can let that one go, as refterm is clearly only a proof of concept, and one-time logic for choosing the correct font at startup would presumably have no effect on rendering speed.
https://i.imgur.com/WeV8Ror.png
no, doesn't work with cascadia either.
so what now?
6 replies →