💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉

[tiangolo]

💄 Use font 'Fira Code' to fix display of Rich panels in docs in Windows

To fix this (detected/reported by @svlandeg):

Description

The issue comes from the fact that Material for MkDocs uses the font "Roboto Mono" by default for code, and the termynal.css styles used the same.

But "Roboto Mono" doesn't include the "glyph" (the visual thing to represent a Unicode character) for the panels: horizontal lines, the corners, and the character ❱.

So, the browser tries to use the next font in the font family. In Linux, it ends up in one that has the glyphs and they are indeed monospace so, it looks mostly good.

In Windows, the next font it finds that has the glyphs is not monospace or doesn't have the glyphs properly monospace (having the exact same width as all the other glyphs in the font), so it looks like unaligned.

Change the font

Changing the font to one that has the glyphs, like Fira Code, fixes most of the issues.

With Fira Code, it's the closest (Chrome on Windows):

Funny enough, on Chrome on Ubuntu (Linux), the same font, looks good:

So there's still something funky going on.

heavy right-pointing angle bracket ornament (❱)

After trying a lot of fonts, my conclusion is that almost no font manages to perfectly render the character ❱ in exactly monospace (with the exact same width as any other character). 😅 ...but it seems to only happen on Windows. 🤯

More strange yet is that running the same script in PowerShell shows the lines perfectly aligned, so there's a potential way for it to properly work, but when trying the theoretical default font of PowerShell, it still looked funky on the browser.

And it also looks funky in other places in Windows.

For example, copying the example in VS Code on Windows:

╭──────────────── Traceback (mostrecentcalllast) ────────────────╮
│ /home/user/code/superapp/main.py:5inmain │
│ │
│ 2 │
│ 3 │
│ 4defmain(name: str="morty"): │
│ ❱ 5 │ print(name+3) │
│ 6 │
│ 7 │
│ 8if__name__=="__main__": │
│ │
│ ╭──── locals ────╮ │
│ │ name='morty' │ │
│ ╰────────────────╯ │
╰───────────────────────────────────────────────────────────────────╯
TypeError: canonlyconcatenatestr (not"int") tostr

...it also renders it a little smaller, so the last bar is also a little moved:

...and here on GitHub, showing that same snippet, on Windows it shows unaligned, on Ubuntu it shows fine.

So, there seems to be an issue with the ❱ glyph on Windows. Not even sure. (?) But for now this should at least make it look better.

2025-11-22 Update: Google Fonts missing glyphs

I discovered I can see the actual font used to render in the developer tools, in the "Computed" section, at the end:

So, it's rendering the ❱ with "Segoe UI Symbol" instead of Roboto Mono, or Fira Code.

This allowed me to keep debugging.

One weird thing is, in the web explorer for Google Fonts, Fira Code and other fonts show up as including that glyph most of the time, but from time to time they show up as not including it, that was strange.

It led me to this issue: google/fonts#4820

It seems the font files and glyphs shown on the web are not necessarily the same ones delivered through the CDN.

So, I went and tried downloading and using Fire Code directly, in regular and bold, downloading the files and serving them locally, and that worked. 🎉 (finally)

Each file is 100 KB. I didn't want to commit that to git if it was not fully necessary. I figured there was a way to load them from a different CDN, from the Fira Code GitHub repo. I used that.

And that finally did it. 🎉

[github-actions]

📝 Docs preview

Last commit 093bf17 at: https://a14273b2.typertiangolo.pages.dev

Modified Pages

• https://a14273b2.typertiangolo.pages.dev/css/custom.css - (before)
• https://a14273b2.typertiangolo.pages.dev/css/termynal.css - (before)

[svlandeg]

Can we use > instead of ❱ ?

[tiangolo]

Yep, I tried that, and it works, but the problem is that these commands are copied as is from the terminal as HTML, so changing it manually wouldn't be sustainable for the long term. 🤔

[willmcgugan]

IIRC we had issues with Fira Code, but had more success with Roboto Mono. Windows in particular as it would break the monospace grid.

Textual serve renders terminals in a similar way, and we used "Roboto Mono", menlo, monospace;

There are also a bunch of CSS rules the impact font rendering. You might want to experiment with text-rendering. Setting that to "geometryPrecission" might help.

You may also want to self host your fonts, if you aren't already. We found that some browsers refused to load fonts from a CDN, which resulted in garbled terminals.

[tiangolo]

Thanks Will!

I was able to figure it out, I added more details in the main description. In short, Google Fonts was not delivering font files with all the glyphs, even if they were shown on the web explorer. Changing the source seems to fix it. 🎉