starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Support for downloadable "soft fonts" (DRCS) #12584

New Issue
Closed
opened 2026-01-31 03:19:29 +00:00 by claunia · 16 comments
claunia commented 2026-01-31 03:19:29 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Feb 14, 2021).

Description of the new feature/enhancement

Starting with the VT220 terminal, it was possible for apps to define their own "soft fonts", also known as dynamically replaceable character sets (DRCS). You would download the font to the terminal with a DECDLD escape sequence, and assign it a character set ID that could then be designated via the usual SCS escape sequences.

Some example use cases:

Custom fonts

image
More examples at https://vt100.net/dec/vt320/fonts

Simple monochromatic images

image

CMatrix with Japanese characters

Source: https://github.com/jhamby/cmatrix
image

Game sprites

image

Proposed technical implementation details (optional)

The screenshots above were taken from a POC I've been working on for conhost. In the current implemenation, when you've designated a DRCS character set, those characters get mapped to values in the Unicode PUA area. Then when the renderer encounters values in that range, it uses a BitBlt to render the glyph in place of the usual PolyTextOut calls.

The quality isn't fantastic - I'm just using StretchBlt to resize the provided glyphs to match the current font size. And the performance can seem a bit sluggish on apps like CMatrix when writing a lot of content to the screen. Nevertheless, I think it works reasonably well, and I'm sure someone smarter than me will have suggestions for how it could be improved.

I'm still a long way from producing a PR, but I wanted to raise the issue now to see how much interest there was in the idea before spending too much time on it. Initially it would be conhost-only - I'm not sure about the conpty feasibility without #1173.

Originally created by @j4james on GitHub (Feb 14, 2021). # Description of the new feature/enhancement Starting with the VT220 terminal, it was possible for apps to define their own "soft fonts", also known as dynamically replaceable character sets (DRCS). You would download the font to the terminal with a `DECDLD` escape sequence, and assign it a character set ID that could then be designated via the usual `SCS` escape sequences. Some example use cases: <details> <summary>Custom fonts</summary> ![image](https://user-images.githubusercontent.com/4181424/107891068-41dd8e00-6f14-11eb-8d4c-37894548e8a4.png) More examples at https://vt100.net/dec/vt320/fonts </details> <details> <summary>Simple monochromatic images</summary> ![image](https://user-images.githubusercontent.com/4181424/107891089-6a658800-6f14-11eb-82b5-7ba8492f0094.png) </details> <details> <summary>CMatrix with Japanese characters</summary> Source: https://github.com/jhamby/cmatrix ![image](https://user-images.githubusercontent.com/4181424/107891093-705b6900-6f14-11eb-92c1-3f52e2b15469.png) </details> <details> <summary>Game sprites</summary> ![image](https://user-images.githubusercontent.com/4181424/107891102-77827700-6f14-11eb-8115-9df758990442.png) </details> # Proposed technical implementation details (optional) The screenshots above were taken from a POC I've been working on for conhost. In the current implemenation, when you've designated a DRCS character set, those characters get mapped to values in the Unicode PUA area. Then when the renderer encounters values in that range, it uses a `BitBlt` to render the glyph in place of the usual `PolyTextOut` calls. The quality isn't fantastic - I'm just using `StretchBlt` to resize the provided glyphs to match the current font size. And the performance can seem a bit sluggish on apps like CMatrix when writing a lot of content to the screen. Nevertheless, I think it works reasonably well, and I'm sure someone smarter than me will have suggestions for how it could be improved. I'm still a long way from producing a PR, but I wanted to raise the issue now to see how much interest there was in the idea before spending too much time on it. Initially it would be conhost-only - I'm not sure about the conpty feasibility without #1173.
claunia commented 2026-01-31 03:19:31 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Feb 15, 2021):

This is extremely cool. I'd love to see it, and I'm sure @miniksa would agree. It does open up a minor can of worms though...

  • If we have support for custom bitmap fonts, folks may revive their (sometimes quote angry) requests for supporting old FON files or whatever weird old bitmap format they wanted
  • I'd love to keep renderer feature divergence between conhost and terminal to a minimum since eventually we're gonna use the DX renderer in conhost; does that make this significantly more difficult as to not be feasible?
  • ConPTY feasibility, as you mentioned -- though I think that it might work if it's treated as a graphic rendition for a line/segment of a line and we have a way to pass off DECDLD¹

None of these concerns is significant enough to stop me from wanting it. Michael may feel differently?

¹ we may experience a 1-frame or (-1)-frame "tear" if the font changes and the sequence is passed through directly (using the quasi-broken conpty "pass through unknown sequences" feature, and without the renderer's consent/knowledge), right? but that's pretty minor.

@DHowett commented on GitHub (Feb 15, 2021): This is **extremely cool**. I'd love to see it, and I'm sure @miniksa would agree. It does open up a minor can of worms though... * If we have support for custom bitmap fonts, folks may revive their (sometimes quote angry) requests for supporting old FON files or whatever weird old bitmap format they wanted * I'd love to keep renderer feature divergence between conhost and terminal to a minimum since eventually we're gonna use the DX renderer in conhost; does that make this significantly more difficult as to not be feasible? * ConPTY feasibility, as you mentioned -- though I think that it might _work_ if it's treated as a graphic rendition for a line/segment of a line and we have a way to pass off `DECDLD`¹ None of these concerns is significant enough to stop _me_ from wanting it. Michael may feel differently? ¹ we may experience a 1-frame or (-1)-frame "tear" if the font changes and the sequence is passed through directly (using the quasi-broken conpty "pass through unknown sequences" feature, and without the renderer's consent/knowledge), right? but that's pretty minor.
claunia commented 2026-01-31 03:19:31 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 15, 2021):

  • I'd love to keep renderer feature divergence between conhost and terminal to a minimum since eventually we're gonna use the DX renderer in conhost; does that make this significantly more difficult as to not be feasible?

I'd very much like that too. And in theory it shouldn't be a problem to add support in the DX renderer, although it might be a bit tricky to test without the conpty side of things. I could probably hack something though.

If you're also thinking about the double-width/height escape sequences, that's more of a political problem. I did initially implement a basic DX renderer for that, but it became clear that it would never work correctly with the way we're handling RTL in Windows Terminal, and I didn't want to start another argument on that subject.

  • ConPTY feasibility, as you mentioned -- though I think that it might work if it's treated as a graphic rendition for a line/segment of a line and we have a way to pass off DECDLD¹

I wouldn't say it definitely can't be done, but it's more complicated than you might think, because fonts can be updated after they've been rendered. To correctly handle that behaviour over conpty would probably require tracking character set data associated with each character. Maybe not impossible, but it seems pointlessly complicated for something that should be trivial with a pass-through version of conpty.

@j4james commented on GitHub (Feb 15, 2021): > * I'd love to keep renderer feature divergence between conhost and terminal to a minimum since eventually we're gonna use the DX renderer in conhost; does that make this significantly more difficult as to not be feasible? I'd very much like that too. And in theory it shouldn't be a problem to add support in the DX renderer, although it might be a bit tricky to test without the conpty side of things. I could probably hack something though. If you're also thinking about the double-width/height escape sequences, that's more of a political problem. I did initially implement a basic DX renderer for that, but it became clear that it would never work correctly with the way we're handling RTL in Windows Terminal, and I didn't want to start another argument on that subject. > * ConPTY feasibility, as you mentioned -- though I think that it might _work_ if it's treated as a graphic rendition for a line/segment of a line and we have a way to pass off `DECDLD`¹ I wouldn't say it definitely can't be done, but it's more complicated than you might think, because fonts can be updated after they've been rendered. To correctly handle that behaviour over conpty would probably require tracking character set data associated with each character. Maybe not impossible, but it seems pointlessly complicated for something that should be trivial with a pass-through version of conpty.
claunia commented 2026-01-31 03:19:31 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 15, 2021):

It just occurred to me that it might be possible to get this working over conpty without that much extra effort if we limited our support to a single font buffer (which was standard for most of the earlier terminals). That way we probably only have to remember the last charset ID, and it should be safe to use that ID for forwarding all soft characters, regardless of the charset they were originally generated with.

I may be missing something, though. I've been through this several times before where I thought I had a plan that would work, then later realized there was a complication I had overlooked. Either way, I'd still prefer to leave this for a follow-up PR. Just getting it working in conhost is going to be complicated enough as it is.

@j4james commented on GitHub (Feb 15, 2021): It just occurred to me that it _might_ be possible to get this working over conpty without that much extra effort if we limited our support to a single font buffer (which was standard for most of the earlier terminals). That way we probably only have to remember the last charset ID, and it should be safe to use that ID for forwarding all soft characters, regardless of the charset they were originally generated with. I may be missing something, though. I've been through this several times before where I thought I had a plan that would work, then later realized there was a complication I had overlooked. Either way, I'd still prefer to leave this for a follow-up PR. Just getting it working in conhost is going to be complicated enough as it is.
claunia commented 2026-01-31 03:19:31 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Feb 16, 2021):

  • ConPTY feasibility, as you mentioned -- though I think that it might work if it's treated as a graphic rendition for a line/segment of a line and we have a way to pass off DECDLD¹

Oh no. What if the conhost can handle all of these fonts and it just emits any of the complexity out the PTY side as sixels and we make Terminal understand sixels? :P

This is extremely cool. I'd love to see it, and I'm sure @miniksa would agree. It does open up a minor can of worms though...

None of these concerns is significant enough to stop me from wanting it. Michael may feel differently?

I do agree though that this is exciting and I'd love to see it. I'm not concerned about any of the issues up front to wholesale stop us from trying to do it.

The quality isn't fantastic - I'm just using StretchBlt to resize the provided glyphs to match the current font size. And the performance can seem a bit sluggish on apps like CMatrix when writing a lot of content to the screen. Nevertheless, I think it works reasonably well, and I'm sure someone smarter than me will have suggestions for how it could be improved.

If you're having trouble with the performance in GDI... I can look at it under the performance analyzer once there's a prototype and see if there's anything to be done. But generally speaking, BitBlt and StretchBlt ought to be hardware accelerated and pretty quick per https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specifying-gdi-hardware-accelerated-rendering-operations. It might be faster to pre-stretch them all to the right size on another in-memory canvas and blt them over from there instead of making it do the stretch calculation every time.

I'd very much like that too. And in theory it shouldn't be a problem to add support in the DX renderer, although it might be a bit tricky to test without the conpty side of things. I could probably hack something though.

If you're also thinking about the double-width/height escape sequences, that's more of a political problem. I did initially implement a basic DX renderer for that, but it became clear that it would never work correctly with the way we're handling RTL in Windows Terminal, and I didn't want to start another argument on that subject.

And as for the DX side...I'm sure we can figure something out. I almost have the vaguest idea of writing all the glyphs into an in-memory font that exposes the interfaces and applying that... or a sprite map sort of thing with blits... hmmmm.

I'm not that worried about the RTL either. If we have to refine RTL further, then we do.

The screenshots above were taken from a POC I've been working on for conhost. In the current implemenation, when you've designated a DRCS character set, those characters get mapped to values in the Unicode PUA area.

I'm a bit worried about using the PUA and having someone have another legitimate use of it that gets in the way. But maybe it's OK to say you can't do both at the same time? I think the only way of avoiding it otherwise would be to attach a specific font override to pieces of the text buffer. Or some sort of flag. A bit ick, but possible.

  • If we have support for custom bitmap fonts, folks may revive their (sometimes quote angry) requests for supporting old FON files or whatever weird old bitmap format they wanted

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN. Not excited about that potential. I want FON files to go die. But it might make it easier to do if there's some sort of bltting thing already established for this.

@miniksa commented on GitHub (Feb 16, 2021): > * ConPTY feasibility, as you mentioned -- though I think that it might _work_ if it's treated as a graphic rendition for a line/segment of a line and we have a way to pass off `DECDLD`¹ Oh no. What if the conhost can handle all of these fonts and it just emits any of the complexity out the PTY side as sixels and we make Terminal understand sixels? :P > This is **extremely cool**. I'd love to see it, and I'm sure @miniksa would agree. It does open up a minor can of worms though... > None of these concerns is significant enough to stop _me_ from wanting it. Michael may feel differently? I do agree though that this is exciting and I'd love to see it. I'm not concerned about any of the issues up front to wholesale stop us from trying to do it. > The quality isn't fantastic - I'm just using `StretchBlt` to resize the provided glyphs to match the current font size. And the performance can seem a bit sluggish on apps like CMatrix when writing a lot of content to the screen. Nevertheless, I think it works reasonably well, and I'm sure someone smarter than me will have suggestions for how it could be improved. If you're having trouble with the performance in GDI... I can look at it under the performance analyzer once there's a prototype and see if there's anything to be done. But generally speaking, BitBlt and StretchBlt ought to be hardware accelerated and pretty quick per https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specifying-gdi-hardware-accelerated-rendering-operations. It might be faster to pre-stretch them all to the right size on another in-memory canvas and blt them over from there instead of making it do the stretch calculation every time. > I'd very much like that too. And in theory it shouldn't be a problem to add support in the DX renderer, although it might be a bit tricky to test without the conpty side of things. I could probably hack something though. > > If you're also thinking about the double-width/height escape sequences, that's more of a political problem. I did initially implement a basic DX renderer for that, but it became clear that it would never work correctly with the way we're handling RTL in Windows Terminal, and I didn't want to start another argument on that subject. And as for the DX side...I'm sure we can figure something out. I almost have the vaguest idea of writing all the glyphs into an in-memory font that exposes the interfaces and applying that... or a sprite map sort of thing with blits... hmmmm. I'm not that worried about the RTL either. If we have to refine RTL further, then we do. > The screenshots above were taken from a POC I've been working on for conhost. In the current implemenation, when you've designated a DRCS character set, those characters get mapped to values in the Unicode PUA area. I'm a bit worried about using the PUA and having someone have another legitimate use of it that gets in the way. But maybe it's OK to say you can't do both at the same time? I think the only way of avoiding it otherwise would be to attach a specific font override to pieces of the text buffer. Or some sort of flag. A bit ick, but possible. > * If we have support for custom bitmap fonts, folks may revive their (sometimes quote angry) requests for supporting old FON files or whatever weird old bitmap format they wanted NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN. Not excited about that potential. I want FON files to go die. But it might make it easier to do if there's some sort of bltting thing already established for this.
claunia commented 2026-01-31 03:19:31 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 16, 2021):

It might be faster to pre-stretch them all to the right size on another in-memory canvas and blt them over from there instead of making it do the stretch calculation every time.

Yeah, I am doing that now, and I think it was an improvement, but it still feels sluggish. My current plan is to see if I can get it working with a run-time raster font, and see if that's any faster. That way I think I can render a whole line of characters with a single GDI call instead of having to do a separate BitBlit for each character - I'm hoping that might make a bit of a difference.

I'm a bit worried about using the PUA and having someone have another legitimate use of it that gets in the way.

This concerned me too. But if we only support a single font buffer, then it's only 96 characters, so I figured we should be able to find a safe gap somewhere that we can reserve. That said, I don't think adding a flag in the TextAttribute class would be such a bad idea either. It might actually make the renderer a little simpler too.

@j4james commented on GitHub (Feb 16, 2021): > It might be faster to pre-stretch them all to the right size on another in-memory canvas and blt them over from there instead of making it do the stretch calculation every time. Yeah, I am doing that now, and I think it was an improvement, but it still feels sluggish. My current plan is to see if I can get it working with a run-time raster font, and see if that's any faster. That way I think I can render a whole line of characters with a single GDI call instead of having to do a separate `BitBlit` for each character - I'm hoping that might make a bit of a difference. > I'm a bit worried about using the PUA and having someone have another legitimate use of it that gets in the way. This concerned me too. But if we only support a single font buffer, then it's only 96 characters, so I figured we should be able to find a safe gap somewhere that we can reserve. That said, I don't think adding a flag in the `TextAttribute` class would be such a bad idea either. It might actually make the renderer a little simpler too.
claunia commented 2026-01-31 03:19:31 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Feb 16, 2021):

It might be faster to pre-stretch them all to the right size on another in-memory canvas and blt them over from there instead of making it do the stretch calculation every time.

Yeah, I am doing that now, and I think it was an improvement, but it still feels sluggish. My current plan is to see if I can get it working with a run-time raster font, and see if that's any faster. That way I think I can render a whole line of characters with a single GDI call instead of having to do a separate BitBlit for each character - I'm hoping that might make a bit of a difference.

Yeah that's sort of the idea I was going for with what I was describing with DirectX... maybe making a fake in-memory font for it and letting those optimizations happen in the text drawing code.

The problem with BitBlt is honestly probably that you're doing a syscall for every single operation. I don't think there's a way around that beyond the font trickery or... composing your own complete bitmap in a chunk of memory in usermode somehow and transferring that whole thing to GDI for rendering at the end. That's really why I was using PolyTextOut in the GDI renderer... calling TextOut in a loop was DEATH in just the syscalls when I did a perf trace on it.

This is where things like DirectWrite will have the blting advantage by composing up a ton of instructions in a queue in user mode and then dispatching them in a chunk. Also it'll run some of it on the GPU probably versus GDI doing virtually all of the work on the CPU. Though I still bet if you can fit it into a font-shaped thing, it'd be faster for both DX and GDI. Or there is technically a DX/DWrite/GDI compatibility shim thing to allow interoperability.... but that may be too crazy.

@miniksa commented on GitHub (Feb 16, 2021): > > It might be faster to pre-stretch them all to the right size on another in-memory canvas and blt them over from there instead of making it do the stretch calculation every time. > > Yeah, I am doing that now, and I think it was an improvement, but it still feels sluggish. My current plan is to see if I can get it working with a run-time raster font, and see if that's any faster. That way I think I can render a whole line of characters with a single GDI call instead of having to do a separate `BitBlit` for each character - I'm hoping that might make a bit of a difference. Yeah that's sort of the idea I was going for with what I was describing with DirectX... maybe making a fake in-memory font for it and letting those optimizations happen in the text drawing code. The problem with `BitBlt` is honestly probably that you're doing a `syscall` for every single operation. I don't think there's a way around that beyond the font trickery or... composing your own complete bitmap in a chunk of memory in usermode somehow and transferring that whole thing to GDI for rendering at the end. That's really why I was using `PolyTextOut` in the GDI renderer... calling `TextOut` in a loop was DEATH in just the syscalls when I did a perf trace on it. This is where things like `DirectWrite` will have the blting advantage by composing up a ton of instructions in a queue in user mode and then dispatching them in a chunk. Also it'll run some of it on the GPU probably versus GDI doing virtually all of the work on the CPU. Though I still bet if you can fit it into a font-shaped thing, it'd be faster for both DX and GDI. Or there is technically a DX/DWrite/GDI compatibility shim thing to allow interoperability.... but that may be too crazy.
claunia commented 2026-01-31 03:19:32 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Feb 16, 2021):

https://devblogs.microsoft.com/oldnewthing/20170331-00/?p=95875 and https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection?

Maybe make a memory section with the bits, fill it up, share it with GDI, and push it all over at once? Woof.

@miniksa commented on GitHub (Feb 16, 2021): https://devblogs.microsoft.com/oldnewthing/20170331-00/?p=95875 and https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection? Maybe make a memory section with the bits, fill it up, share it with GDI, and push it all over at once? Woof.
claunia commented 2026-01-31 03:19:32 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Feb 18, 2021):

Maybe make a memory section with the bits, fill it up, share it with GDI, and push it all over at once? Woof.

Now that you mention that, I did actually try using SetDIBitsToDevice, thinking it might help if I could use it to blit out a whole sequence of characters in one call, but that also didn't seem to work very well with the CMatrix test. I've since realised that that's probably because of the way CMatrix is updating the screen - we get a lot of individual characters being drawn at different locations rather than a nice neat sequences that can be chunked together. But maybe there's still hope for a font-based approach using PolyText.

Also I need to slow down a bit and do thing properly. So far I've just been hacking things together to get a general idea of what works and what doesn't, but it's quite possible my hacky code is part of the problem. I'm not ruling anything out until I've had a chance to try and implement things properly.

@j4james commented on GitHub (Feb 18, 2021): > Maybe make a memory section with the bits, fill it up, share it with GDI, and push it all over at once? Woof. Now that you mention that, I did actually try using `SetDIBitsToDevice`, thinking it might help if I could use it to blit out a whole sequence of characters in one call, but that also didn't seem to work very well with the CMatrix test. I've since realised that that's probably because of the way CMatrix is updating the screen - we get a lot of individual characters being drawn at different locations rather than a nice neat sequences that can be chunked together. But maybe there's still hope for a font-based approach using `PolyText`. Also I need to slow down a bit and do thing properly. So far I've just been hacking things together to get a general idea of what works and what doesn't, but it's quite possible my hacky code is part of the problem. I'm not ruling anything out until I've had a chance to try and implement things properly.
claunia commented 2026-01-31 03:19:32 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 6, 2021):

FYI, I've got a PR ready to submit for this, but it's branched off of PR #9307, so I'm waiting for that to merge first. This is still conhost only, and I've no immediate plans to work on the DX/conpty side of things, so there's no urgency to prioritize this from a Windows Terminal point of view. Just letting you know it's available if you want it.

@j4james commented on GitHub (Apr 6, 2021): FYI, I've got a PR ready to submit for this, but it's branched off of PR #9307, so I'm waiting for that to merge first. This is still conhost only, and I've no immediate plans to work on the DX/conpty side of things, so there's no urgency to prioritize this from a Windows Terminal point of view. Just letting you know it's available if you want it.
claunia commented 2026-01-31 03:19:32 +00:00
Author
Owner
Copy Link

@miniksa commented on GitHub (Apr 14, 2021):

FYI, I've got a PR ready to submit for this, but it's branched off of PR #9307, so I'm waiting for that to merge first. This is still conhost only, and I've no immediate plans to work on the DX/conpty side of things, so there's no urgency to prioritize this from a Windows Terminal point of view. Just letting you know it's available if you want it.

Yes I want it even if it's conhost only. At least there's a reference impl for me to work from to port it to DX eventually. Sorry I've been so out of it on reviewing these.

@miniksa commented on GitHub (Apr 14, 2021): > FYI, I've got a PR ready to submit for this, but it's branched off of PR #9307, so I'm waiting for that to merge first. This is still conhost only, and I've no immediate plans to work on the DX/conpty side of things, so there's no urgency to prioritize this from a Windows Terminal point of view. Just letting you know it's available if you want it. Yes I want it even if it's conhost only. At least there's a reference impl for me to work from to port it to DX eventually. Sorry I've been so out of it on reviewing these.
claunia commented 2026-01-31 03:19:33 +00:00
Author
Owner
Copy Link

@dotnetCarpenter commented on GitHub (Apr 15, 2021):

Just a quick question to set expectations for this feature.

@DHowett mentions that PCF fonts will never be supported but that DRCS fonts can be used in place of PCF. I googled conversions from PCF to DRCS but came up empty handed (it seems that DRCS font by itself does not yield many results).

But how about .fnt files? Will those be supported or is there a conversion tool available to generate DRCS fonts from various fonts? I guess what I'm aiming at, is how would I go about using this feature without being an artist?

Screen-shot of the rendered matrix.fnt
Screen-shot rendering of matrix.fnt with RECOIL for Windows

fnt.zip

@dotnetCarpenter commented on GitHub (Apr 15, 2021): **Just a quick question to set expectations for this feature.** @DHowett [mentions that PCF fonts will never be supported](https://github.com/microsoft/terminal/issues/9830#issuecomment-819957331) but that DRCS fonts can be used in place of PCF. I googled conversions from PCF to DRCS but came up empty handed (it seems that DRCS font by itself does not yield many results). But how about `.fnt` files? Will those be supported or is there a conversion tool available to generate DRCS fonts from various fonts? I guess what I'm aiming at, is how would I go about using this feature without being an artist? ![Screen-shot of the rendered matrix.fnt](https://user-images.githubusercontent.com/43763/114862451-d702e300-9dee-11eb-93f6-e101aea017a9.png) _Screen-shot rendering of [matrix.fnt](https://github.com/microsoft/terminal/files/6317511/fnt.zip) with [RECOIL for Windows](https://www.microsoft.com/en-us/p/recoil/9nblggh4132z?activetab=pivot:overviewtab)_ [fnt.zip](https://github.com/microsoft/terminal/files/6317511/fnt.zip)
claunia commented 2026-01-31 03:19:33 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 15, 2021):

In theory, converting a raster .fnt file to DRCS shouldn't be too difficult, but there are a couple of limitations you need to be aware of.

  1. DRCS fonts are limited to 96 characters, while a .fnt file can have up to 256 I think. In theory you could have two DRCS fonts, one mapping characters 32 to 127, and another mapping 160 to 255, which gets you closer to a full .fnt file, but my DRCS implementation doesn't support multiple font buffers yet, so you can't display both sets at the same time. Maybe in a future update.

  2. Raster fonts are designed to work at a specific resolution, but in the terminal we need to render the glyphs at the same size as your current terminal font. That will often require some stretching or shrinking, so the quality won't be perfect. But if you choose your terminal font and font size appropriately, you can potentially work around those issues.

But if you just want Cmatrix with the cool characters, there's already a fork that uses DRCS to achieve that. See the link and screenshot above.

@j4james commented on GitHub (Apr 15, 2021): In theory, converting a raster .fnt file to DRCS shouldn't be too difficult, but there are a couple of limitations you need to be aware of. 1. DRCS fonts are limited to 96 characters, while a .fnt file can have up to 256 I think. In theory you could have two DRCS fonts, one mapping characters 32 to 127, and another mapping 160 to 255, which gets you closer to a full .fnt file, but my DRCS implementation doesn't support multiple font buffers yet, so you can't display both sets at the same time. Maybe in a future update. 2. Raster fonts are designed to work at a specific resolution, but in the terminal we need to render the glyphs at the same size as your current terminal font. That will often require some stretching or shrinking, so the quality won't be perfect. But if you choose your terminal font and font size appropriately, you can potentially work around those issues. But if you just want Cmatrix with the cool characters, there's already a fork that uses DRCS to achieve that. See the link and screenshot above.
claunia commented 2026-01-31 03:19:33 +00:00
Author
Owner
Copy Link

@dotnetCarpenter commented on GitHub (Aug 26, 2021):

@j4james I assume you mean https://github.com/jhamby/cmatrix and you're absolutely right!

I removed my apt version of cmatrix and installed jhamby/cmatrix from source.

However, using terminal Version: 1.9.1942.0 on Ubuntu 21.04 and the output with cmatrix -3 looks nothing like expected. Using cmatrix -lba and I'm back to #9830 which is closed as a duplicate of this issue...

How did you run your tests for #10011?

PS. Sorry for the very late reply

@dotnetCarpenter commented on GitHub (Aug 26, 2021): @j4james I assume you mean https://github.com/jhamby/cmatrix and you're absolutely right! I removed my apt version of `cmatrix` and installed _jhamby/cmatrix_ from source. However, using terminal Version: 1.9.1942.0 on Ubuntu 21.04 and the output with `cmatrix -3` looks nothing like expected. Using `cmatrix -lba` and I'm back to #9830 which is closed as a duplicate of this issue... How did you run your tests for #10011? PS. Sorry for the very late reply
claunia commented 2026-01-31 03:19:34 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Aug 26, 2021):

@dotnetCarpenter FWIW #10011 hasn't shipped in any terminal release yet - 1.11 will be the first that has it

@zadjii-msft commented on GitHub (Aug 26, 2021): @dotnetCarpenter FWIW #10011 hasn't shipped in _any_ terminal release yet - 1.11 will be the first that has it
claunia commented 2026-01-31 03:19:34 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 26, 2021):

However, Terminal doesn't support DRCS yet. Only the Windows Console host shipped inside Terminal does!

@DHowett commented on GitHub (Aug 26, 2021): However, Terminal doesn't support DRCS yet. Only the Windows Console host shipped inside Terminal does!
claunia commented 2026-01-31 03:19:34 +00:00
Author
Owner
Copy Link

@dotnetCarpenter commented on GitHub (Aug 26, 2021):

@DHowett cmatrix for Windows then? ;-D

@dotnetCarpenter commented on GitHub (Aug 26, 2021): @DHowett `cmatrix` for Windows then? ;-D
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Rendering Area-VT Issue-Feature Product-Conhost Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#12584
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?