Font rendering issues in Terminal #871

@mqudsi commented on GitHub (May 14, 2019):

No, that is SF Mono. SF Console is a clone intended to look like it but not one I'm authorized to share; which is why I mention Roboto Slab, which is open source and publicly available.

@mqudsi commented on GitHub (May 14, 2019): No, that is SF Mono. SF Console is a clone intended to look like it but not one I'm authorized to share; which is why I mention Roboto Slab, which _is_ open source and publicly available.

claunia commented

@miniksa commented on GitHub (May 14, 2019):

Where can I get it and confirm the licensing?

@miniksa commented on GitHub (May 14, 2019): Where can I get it and confirm the licensing?

claunia commented

@mqudsi commented on GitHub (May 14, 2019):

It's made by Google, released under the Apache 2.0 license. GitHub repo: https://github.com/googlefonts/robotoslab

You can download the prebuilt TrueType files here: https://github.com/google/fonts/tree/master/apache/robotoslab

@mqudsi commented on GitHub (May 14, 2019): It's made by Google, released under the Apache 2.0 license. GitHub repo: https://github.com/googlefonts/robotoslab You can download the prebuilt TrueType files here: https://github.com/google/fonts/tree/master/apache/robotoslab

claunia commented

@miniksa commented on GitHub (May 14, 2019):

OK thanks. I'll take a look at it then when I get around to being able to work on rendering stuff instead of triaging GitHub issues and PRs all day. :P

@miniksa commented on GitHub (May 14, 2019): OK thanks. I'll take a look at it then when I get around to being able to work on rendering stuff instead of triaging GitHub issues and PRs all day. :P

claunia commented

@iKlsR commented on GitHub (Jun 10, 2019):

I'm having a similar issue, I can only seem to use the base regular font, any medium or other variation and the app won't start and changes to a very tiny clipped variation if already running similar to the 4th screenshot. Font is Fira Code. Fira Code Medium works fine everywhere else.

@iKlsR commented on GitHub (Jun 10, 2019): I'm having a similar issue, I can only seem to use the base regular font, any medium or other variation and the app won't start and changes to a very tiny clipped variation if already running similar to the 4th screenshot. Font is Fira Code. Fira Code Medium works fine everywhere else.

claunia commented

2026-01-30 22:07:43 +00:00

@mdtauk commented on GitHub (Jun 10, 2019):

If the new terminal is going to support Bold and Italic fonts, shouldn't the font picker be showing Font Families, rather than individual fonts?

@mdtauk commented on GitHub (Jun 10, 2019): If the new terminal is going to support Bold and Italic fonts, shouldn't the font picker be showing Font Families, rather than individual fonts?

claunia commented

@DHowett-MSFT commented on GitHub (Jun 10, 2019):

I mean, there isn’t a font picker right now, so it isn’t showing anything?

@DHowett-MSFT commented on GitHub (Jun 10, 2019): I mean, there isn’t a font picker right now, so it isn’t showing anything?

claunia commented

2026-01-30 22:07:43 +00:00

@mdtauk commented on GitHub (Jun 10, 2019):

I mean, there isn’t a font picker right now, so it isn’t showing anything?

True, but the fact the font picked is not of a regular weight, it could be part of the problem. But I assume the plan is to have a font picker in an app setting dialog of some kind :)

@mdtauk commented on GitHub (Jun 10, 2019): > I mean, there isn’t a font picker right now, so it isn’t showing anything? True, but the fact the font picked is not of a regular weight, it could be part of the problem. But I assume the plan is to have a font picker in an app setting dialog of some kind :)

claunia commented

2026-01-30 22:07:43 +00:00

@mqudsi commented on GitHub (Jun 10, 2019):

I think a good question is whether individual fonts within a family are looked up by their common name or their postscript name.

@mqudsi commented on GitHub (Jun 10, 2019): I think a good question is whether individual fonts within a family are looked up by their common name or their postscript name.

claunia commented

2026-01-30 22:07:44 +00:00

@zadjii-msft commented on GitHub (Jun 10, 2019):

Also maybe related: #1163

@zadjii-msft commented on GitHub (Jun 10, 2019): Also maybe related: #1163

claunia commented

2026-01-30 22:07:45 +00:00

@vsalvino commented on GitHub (Jun 13, 2019):

This issue occurs with any font using the non-regular weight. For Example, IBM Plex Mono provides a ton of weights, none of them work in the terminal except regular specified with "fontFace": "IBM Plex Mono". Specifying "fontFace": "IBM Plex Mono Medium" produces the same rendering issue above.

@vsalvino commented on GitHub (Jun 13, 2019): This issue occurs with any font using the non-regular weight. For Example, [IBM Plex Mono](https://fonts.google.com/specimen/IBM+Plex+Mono) provides a ton of weights, none of them work in the terminal except regular specified with `"fontFace": "IBM Plex Mono"`. Specifying `"fontFace": "IBM Plex Mono Medium"` produces the same rendering issue above.

claunia commented

2026-01-30 22:07:45 +00:00

@bmo-at commented on GitHub (Jul 15, 2019):

This issue occurs with any font using the non-regular weight. For Example, IBM Plex Mono provides a ton of weights, none of them work in the terminal except regular specified with "fontFace": "IBM Plex Mono". Specifying "fontFace": "IBM Plex Mono Medium" produces the same rendering issue above.

Same for Nerd Fonts. As long as regular is installed, regular will be used. If you uninstall everything but, say for example bold, bold is used instead. This should instead be configurable in the settings file, with another attribute (e.g. fontWeight) for the profile:

        {
            "acrylicOpacity" : 0.5,
            "closeOnExit" : true,
            "colorScheme" : "One Dark Pro",
            "commandline" : "wsl.exe -d Debian",
...
            "fontFace" : "Hack NF",
            "fontSize" : 11,
            "fontWeight": "bold",
...
            "useAcrylic" : true
        }

@bmo-at commented on GitHub (Jul 15, 2019): > This issue occurs with any font using the non-regular weight. For Example, [IBM Plex Mono](https://fonts.google.com/specimen/IBM+Plex+Mono) provides a ton of weights, none of them work in the terminal except regular specified with `"fontFace": "IBM Plex Mono"`. Specifying `"fontFace": "IBM Plex Mono Medium"` produces the same rendering issue above. Same for [Nerd Fonts](https://github.com/ryanoasis/nerd-fonts). As long as regular is installed, regular will be used. If you uninstall everything but, say for example bold, bold is used instead. This should instead be configurable in the settings file, with another attribute (e.g. ```fontWeight```) for the profile: ```json { "acrylicOpacity" : 0.5, "closeOnExit" : true, "colorScheme" : "One Dark Pro", "commandline" : "wsl.exe -d Debian", ... "fontFace" : "Hack NF", "fontSize" : 11, "fontWeight": "bold", ... "useAcrylic" : true } ```

claunia commented

2026-01-30 22:07:46 +00:00

@miniksa commented on GitHub (Jul 15, 2019):

This issue occurs with any font using the non-regular weight. For Example, IBM Plex Mono provides a ton of weights, none of them work in the terminal except regular specified with "fontFace": "IBM Plex Mono". Specifying "fontFace": "IBM Plex Mono Medium" produces the same rendering issue above.

Thanks for the datapoint. I don't think I tried non-"regular" font weights yet while originally writing the renderer. This is probably just something I overlooked and need to finish writing.

Same for Nerd Fonts. As long as regular is installed, regular will be used. If you uninstall everything but, say for example bold, bold is used instead. This should instead be configurable in the settings file, with another attribute (e.g. fontWeight) for the profile:

I agree, it should be configurable. I just haven't got around to it yet.

@miniksa commented on GitHub (Jul 15, 2019): > This issue occurs with any font using the non-regular weight. For Example, [IBM Plex Mono](https://fonts.google.com/specimen/IBM+Plex+Mono) provides a ton of weights, none of them work in the terminal except regular specified with `"fontFace": "IBM Plex Mono"`. Specifying `"fontFace": "IBM Plex Mono Medium"` produces the same rendering issue above. Thanks for the datapoint. I don't think I tried non-"regular" font weights yet while originally writing the renderer. This is probably just something I overlooked and need to finish writing. > Same for [Nerd Fonts](https://github.com/ryanoasis/nerd-fonts). As long as regular is installed, regular will be used. If you uninstall everything but, say for example bold, bold is used instead. This should instead be configurable in the settings file, with another attribute (e.g. `fontWeight`) for the profile: I agree, it should be configurable. I just haven't got around to it yet.

claunia commented

2026-01-30 22:07:46 +00:00

@bmo-at commented on GitHub (Jul 15, 2019):

Just had to give a shoutout to you guys for how ballin this Terminal is already. Performance is like greased lightning, visuals are terrific and stability is very good for such an early preview.
The switching for different kinds of shells (PS, cmd and wsl) is terrifc also.

Keep it going! 💪🏻

@bmo-at commented on GitHub (Jul 15, 2019): ![image](https://user-images.githubusercontent.com/5568767/61248340-28ca9500-a753-11e9-8346-218915f36a63.png) Just had to give a shoutout to you guys for how ballin this Terminal is already. Performance is like greased lightning, visuals are terrific and stability is very good for such an early preview. The switching for different kinds of shells (PS, cmd and wsl) is terrifc also. Keep it going! 💪🏻

claunia commented

2026-01-30 22:07:46 +00:00

@offero commented on GitHub (Aug 7, 2019):

Another example

Victor Mono font (https://github.com/rubjo/victor-mono/)

@offero commented on GitHub (Aug 7, 2019): Another example ![image](https://user-images.githubusercontent.com/4681330/62652651-da5f7f00-b929-11e9-9b3b-4ca94f8cc5f5.png) Victor Mono font (https://github.com/rubjo/victor-mono/)

claunia commented

2026-01-30 22:07:47 +00:00

@BinaryInk commented on GitHub (Aug 28, 2019):

And another example if it helps... Share Tech Mono (https://fonts.google.com/specimen/Share+Tech+Mono) -- easily reproducible in PowerShell errors. There's no additional weights/styles for this font.

@BinaryInk commented on GitHub (Aug 28, 2019): And another example if it helps... Share Tech Mono (https://fonts.google.com/specimen/Share+Tech+Mono) -- easily reproducible in PowerShell errors. There's no additional weights/styles for this font. ![image](https://user-images.githubusercontent.com/12054014/63814755-8e37a700-c8f7-11e9-94d4-f2b3ccdfa815.png)

claunia commented

2026-01-30 22:07:47 +00:00

@danieldjewell commented on GitHub (Dec 23, 2019):

@miniksa I know it's on the radar to get this addressed - not sure if you have an implementation plan in mind already (and if so, forgive my armchair programming....)

FWIW, Terminal seems to be completely naïve to the existence of multiple font variants as it's not possible to even type the full name of the font... (In VSCode there is an editor.fontWeight setting but I believe it's possible to specify the font weight variant in the font family list... I haven't played with the font APIs in a really long time, so not sure if specifying the weight variant after the name just implies a font weight as opposed to a completely different font name.)

Also, if possible, it would be cool to have the ability to bypass the Windows Font subsystem and specify a (woff/ttf/otf) font file directly (if that's an easy option) -- I've run into issues with locked down workstations where I want to use a different font but can't install it at all.

As a possible workaround in the meantime, it might be possible to edit the font name itself to be different so that Windows doesn't see it as a variant but as a completely different font...

E.g. from "Fira Code Bold" TTF -- actually changing the name to be say "Fira Code Alt Bold" and setting the variant to Regular. (See ttfdump -t name FiraCode-Bold.ttf output below)

Name table   1.  PlatformID:     1
                 EncodingID:     0
                 LanguageID:     0
                 NameID:         1
                 Length:         9
                 Offset:         86
                 46 69 72 61 20 43 6f 64 65     > Fira Code
Name table   2.  PlatformID:     1
                 EncodingID:     0
                 LanguageID:     0
                 NameID:         2
                 Length:         4
                 Offset:         95
                 42 6f 6c 64                    > Bold
Name table   3.  PlatformID:     1
                 EncodingID:     0
                 LanguageID:     0
                 NameID:         3
                 Length:         24
                 Offset:         99
                 32 2e 30 30 30 3b 43 54 44 42  >  2.000;CTDB
                 3b 46 69 72 61 43 6f 64 65 2d  >  ;FiraCode-
                 42 6f 6c 64                    > Bold
Name table   4.  PlatformID:     1
                 EncodingID:     0
                 LanguageID:     0
                 NameID:         4
                 Length:         14
                 Offset:         123
                 46 69 72 61 20 43 6f 64 65 20  >  Fira Code
                 42 6f 6c 64                    > Bold

@danieldjewell commented on GitHub (Dec 23, 2019): @miniksa I know it's on the radar to get this addressed - not sure if you have an implementation plan in mind already (and if so, forgive my armchair programming....) FWIW, Terminal seems to be completely naïve to the existence of multiple font variants as it's not possible to even type the full name of the font... (In VSCode there *is* an ``` editor.fontWeight ``` setting but I believe it's possible to specify the font weight variant in the font family list... I haven't played with the font APIs in a really long time, so not sure if specifying the weight variant after the name just implies a font weight as opposed to a completely different font name.) Also, if possible, it would be cool to have the ability to bypass the Windows Font subsystem and specify a (woff/ttf/otf) font file directly (if that's an easy option) -- I've run into issues with locked down workstations where I want to use a different font but can't install it at all. As a possible workaround in the meantime, it might be possible to edit the font name itself to be different so that Windows doesn't see it as a variant but as a completely different font... E.g. from "Fira Code Bold" TTF -- actually changing the name to be say "Fira Code Alt Bold" and setting the variant to Regular. (See ``` ttfdump -t name FiraCode-Bold.ttf ``` output below) ``` Name table 1. PlatformID: 1 EncodingID: 0 LanguageID: 0 NameID: 1 Length: 9 Offset: 86 46 69 72 61 20 43 6f 64 65 > Fira Code Name table 2. PlatformID: 1 EncodingID: 0 LanguageID: 0 NameID: 2 Length: 4 Offset: 95 42 6f 6c 64 > Bold Name table 3. PlatformID: 1 EncodingID: 0 LanguageID: 0 NameID: 3 Length: 24 Offset: 99 32 2e 30 30 30 3b 43 54 44 42 > 2.000;CTDB 3b 46 69 72 61 43 6f 64 65 2d > ;FiraCode- 42 6f 6c 64 > Bold Name table 4. PlatformID: 1 EncodingID: 0 LanguageID: 0 NameID: 4 Length: 14 Offset: 123 46 69 72 61 20 43 6f 64 65 20 > Fira Code 42 6f 6c 64 > Bold ```

claunia commented

2026-01-30 22:07:47 +00:00

@miniksa commented on GitHub (Jan 2, 2020):

@danieldjewell, it appears that DirectWrite does have provisions to effectively "do whatever you want" in terms of loading fonts, up to and including what you proposed of directly specifying a font file: https://docs.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollectionloader

It would just take someone coding that up in the DirectX/DirectWrite rendering engine and piping a setting all the way through to make it happen.

@miniksa commented on GitHub (Jan 2, 2020): @danieldjewell, it appears that DirectWrite does have provisions to effectively "do whatever you want" in terms of loading fonts, up to and including what you proposed of directly specifying a font file: https://docs.microsoft.com/en-us/windows/win32/api/dwrite/nn-dwrite-idwritefontcollectionloader It would just take someone coding that up in the DirectX/DirectWrite rendering engine and piping a setting all the way through to make it happen.

claunia commented

2026-01-30 22:07:48 +00:00

@horseinthesky commented on GitHub (Jan 16, 2020):

DejaVuSansMono NF https://github.com/ryanoasis/nerd-fonts/blob/master/patched-fonts/DejaVuSansMono/Regular/complete/DejaVu%20Sans%20Mono%20Nerd%20Font%20Complete.ttf
is broken too:

Here is how it should look like:

@horseinthesky commented on GitHub (Jan 16, 2020): `DejaVuSansMono NF` https://github.com/ryanoasis/nerd-fonts/blob/master/patched-fonts/DejaVuSansMono/Regular/complete/DejaVu%20Sans%20Mono%20Nerd%20Font%20Complete.ttf is broken too: ![image](https://user-images.githubusercontent.com/19948672/72503508-ec383d00-384c-11ea-9b85-824a9531016f.png) Here is how it should look like: ![image](https://user-images.githubusercontent.com/19948672/72503592-230e5300-384d-11ea-9ca2-d8fa0b3aa79e.png)

claunia commented

2026-01-30 22:07:48 +00:00

@MartinSGill commented on GitHub (Jan 29, 2020):

Another example that seems a bit different from those I've already seen.

Note how the font style/weight changes for the time on the second line. It then fails to render both the final chevron and the >_ character.

Compare this to the same prompt in a different terminal app.

Font in this case is Fura Code NF

@MartinSGill commented on GitHub (Jan 29, 2020): Another example that seems a bit different from those I've already seen. ![image](https://user-images.githubusercontent.com/2271740/73363940-eeb58080-42a9-11ea-90ff-0039457b615a.png) Note how the font style/weight changes for the time on the second line. It then fails to render both the final chevron and the >_ character. Compare this to the same prompt in a different terminal app. ![image](https://user-images.githubusercontent.com/2271740/73364207-6f747c80-42aa-11ea-97f8-b57c8cce7360.png) Font in this case is [Fura Code NF](https://github.com/ryanoasis/nerd-fonts/tree/master/patched-fonts/FiraCode)

claunia commented

2026-01-30 22:07:48 +00:00

@austinwagner commented on GitHub (Feb 9, 2020):

I'm seeing the same issue with PragmataPro. It appears it's because the font isn't truly monospace. Some code points map to double or triple wide glyphs (PragmataPro Mono works because these wide glyphs are squished, but it also drops Nerd Fonts glyphs).

Oddly, the size returns to normal when the color changes:

echo -e '\e[31m\u2026\e[31mx'
echo -e '\e[31m\u2026\e[32mx'

@austinwagner commented on GitHub (Feb 9, 2020): I'm seeing the same issue with PragmataPro. It appears it's because the font isn't truly monospace. Some code points map to double or triple wide glyphs (PragmataPro Mono works because these wide glyphs are squished, but it also drops Nerd Fonts glyphs). Oddly, the size returns to normal when the color changes: ``` echo -e '\e[31m\u2026\e[31mx' echo -e '\e[31m\u2026\e[32mx' ``` ![image](https://user-images.githubusercontent.com/556352/74097174-045f4d00-4ad7-11ea-930a-890eb809cc68.png)

claunia commented

2026-01-30 22:07:49 +00:00

@johnwildes commented on GitHub (Feb 20, 2020):

UPDATE: The DPI Scaling on my monitors was set to 125% and this is what was causing the gaps in the powerline font below. Changing the DPI Scaling to 100% fixes it but now things are smaller 😂 . Not sure if this would be something to look into fixing.

I apologize if this isn't the right place to log this, but I didn't think it would be appropriate to open a new issue. I'm having some rendering issues with powerline font in both powershell and wsl/ubuntu. I'm using the most recent Cascadia Code PL font. What you can see from the prompt is that there's some thin lines that separate each section of the prompt. This is sub-optimal, when this didn't exist before, and doesn't exist in other renderings (like the VSCODE terminal).

Running Windows Terminal (Preview)
Version: 0.9.433.0

Cascadia Code PL 1911.21

@johnwildes commented on GitHub (Feb 20, 2020): UPDATE: The DPI Scaling on my monitors was set to 125% and this is what was causing the gaps in the powerline font below. Changing the DPI Scaling to 100% fixes it but now things are smaller :joy: . Not sure if this would be something to look into fixing. I apologize if this isn't the right place to log this, but I didn't think it would be appropriate to open a new issue. I'm having some rendering issues with powerline font in both powershell and wsl/ubuntu. I'm using the most recent Cascadia Code PL font. What you can see from the prompt is that there's some thin lines that separate each section of the prompt. This is sub-optimal, when this didn't exist before, and doesn't exist in other renderings (like the VSCODE terminal). ![image](https://user-images.githubusercontent.com/1375512/74890416-8bb78680-5349-11ea-894b-9b45e040c723.png) ![image](https://user-images.githubusercontent.com/1375512/74890426-92de9480-5349-11ea-816e-8e2cfb5029f9.png) Running Windows Terminal (Preview) Version: 0.9.433.0 Cascadia Code PL 1911.21

claunia commented

2026-01-30 22:07:49 +00:00

@DHowett-MSFT commented on GitHub (Feb 21, 2020):

Quick repro for me:

Install Fixedsys Excelsior (here)
Run CMD in WT
type <><>

@DHowett-MSFT commented on GitHub (Feb 21, 2020): Quick repro for me: Install Fixedsys Excelsior ([here](https://github.com/kika/fixedsys/releases)) Run CMD in WT type `<><>` ![image](https://user-images.githubusercontent.com/14316954/74993104-db0bbe80-53fe-11ea-85f2-9ddc88102598.png)

claunia commented

2026-01-30 22:07:49 +00:00

@shanselman commented on GitHub (Mar 3, 2020):

Not sure where to file this. Could be in Cascadia Code itself @cinnamon-msft or could be Terminal Version: 0.9.433.0.

Repro is easy. "echo ⚡" with Cascadia Code PL vs using the patched DelugiaCode NF.

Note it on the command line vs when used in a prompt. This is DelugiaCodeNF 1909.16 (just a patched Cascadia). It's not in color on the prompt, then it's color in the prompt. But the size is right.

And this is Cascadia Code PL 1911.21. It's color everywhere but tiny.

@shanselman commented on GitHub (Mar 3, 2020): Not sure where to file this. Could be in Cascadia Code itself @cinnamon-msft or could be Terminal Version: 0.9.433.0. Repro is easy. "echo ⚡" with Cascadia Code PL vs using the patched DelugiaCode NF. Note it on the command line vs when used in a prompt. This is DelugiaCodeNF 1909.16 (just a patched Cascadia). It's not in color on the prompt, then it's color in the prompt. But the size is right. ![image](https://user-images.githubusercontent.com/2892/75754234-36805b00-5ce1-11ea-83b6-c05465186959.png) And this is Cascadia Code PL 1911.21. It's color everywhere but tiny. ![image](https://user-images.githubusercontent.com/2892/75754283-4dbf4880-5ce1-11ea-9cfd-0dff0eca44e7.png)

claunia commented

2026-01-30 22:07:50 +00:00

@austinwagner commented on GitHub (Mar 3, 2020):

@shanselman Is the color part a bug? It looks to me like a lightning bolt glyph was added into the patched font and that the unpatched font is falling back on the default Windows emoji glyph.

@austinwagner commented on GitHub (Mar 3, 2020): @shanselman Is the color part a bug? It looks to me like a lightning bolt glyph was added into the patched font and that the unpatched font is falling back on the default Windows emoji glyph.

claunia commented

2026-01-30 22:07:50 +00:00

@shanselman commented on GitHub (Mar 3, 2020):

@austinwagner The bug (behaviorally) is the small/wrong size. You're saying that Cascadia has a small glyph inside and that is wrong?

@shanselman commented on GitHub (Mar 3, 2020): @austinwagner The bug (behaviorally) is the small/wrong size. You're saying that Cascadia has a small glyph inside and that is wrong?

claunia commented

2026-01-30 22:07:50 +00:00

@austinwagner commented on GitHub (Mar 3, 2020):

@shanselman Apologies for being unclear. I was referring to the color difference only. The size is almost certainly wrong.

@austinwagner commented on GitHub (Mar 3, 2020): @shanselman Apologies for being unclear. I was referring to the color difference only. The size is almost certainly wrong.

claunia commented

@gitfool commented on GitHub (Mar 3, 2020):

I have a similar size issue with the Kubernetes Helm symbol ⎈ (U+2388) and the Fira Code font:

@gitfool commented on GitHub (Mar 3, 2020): I have a similar size issue with the Kubernetes Helm symbol ⎈ (U+2388) and the [Fira Code](https://github.com/tonsky/FiraCode) font: ![image](https://user-images.githubusercontent.com/750121/75808346-d1fdf280-5deb-11ea-9d89-a0949f1c4f1d.png)

claunia commented

@DHowett-MSFT commented on GitHub (Mar 3, 2020):

Good, good, y'all can head over to #900

@DHowett-MSFT commented on GitHub (Mar 3, 2020): Good, good, y'all can head over to #900

claunia commented

@DHowett-MSFT commented on GitHub (Mar 3, 2020):

This is in fact a bug submitted by @shanselman himself so 🤷‍♂

@DHowett-MSFT commented on GitHub (Mar 3, 2020): This is in fact a bug submitted by @shanselman himself so 🤷‍♂

claunia commented

@calloncampbell commented on GitHub (Mar 5, 2020):

I followed the instructions by @shanselman post https://www.hanselman.com/blog/HowToMakeAPrettyPromptInWindowsTerminalWithPowerlineNerdFontsCascadiaCodeWSLAndOhmyposh.aspx and I still see wonky icons.

Windows Terminal version 0.9.433.0

@calloncampbell commented on GitHub (Mar 5, 2020): I followed the instructions by @shanselman post https://www.hanselman.com/blog/HowToMakeAPrettyPromptInWindowsTerminalWithPowerlineNerdFontsCascadiaCodeWSLAndOhmyposh.aspx and I still see wonky icons. Windows Terminal version 0.9.433.0 ![image](https://user-images.githubusercontent.com/4095080/76001529-39db3880-5ed3-11ea-86fd-764ecabfeea2.png)

claunia commented

@shanselman commented on GitHub (Mar 6, 2020):

@calloncampbell I'll help you via twitter, not in a GH issue

@shanselman commented on GitHub (Mar 6, 2020): @calloncampbell I'll help you via twitter, not in a GH issue

claunia commented

@calloncampbell commented on GitHub (Mar 6, 2020):

OK my issue is not related. I had downloaded the wrong font. Thanks @shanselman for the help.

@calloncampbell commented on GitHub (Mar 6, 2020): OK my issue is not related. I had downloaded the wrong font. Thanks @shanselman for the help.

claunia commented

@sergio-u commented on GitHub (Mar 27, 2020):

This may be related: glyphs in some fixed rows appear "ghosted" in the bottom half (the whole row). I am using Cascadia Mono PL (no ligatures) and ClearType rendering.

By fixed I mean that after scrolling, the text in a different row renders fine, but the text entering the affected row is rendered badly.

For example, the "eviously" is rendered badly in the screenshot, but after scrolling a single line, it would render okay, but "Pages" would not.

@sergio-u commented on GitHub (Mar 27, 2020): This may be related: glyphs in some _fixed_ rows appear "ghosted" in the bottom half (the whole row). I am using Cascadia Mono PL (no ligatures) and ClearType rendering. By _fixed_ I mean that after scrolling, the text in a different row renders fine, but the text entering the affected row is rendered badly. For example, the "eviously" is rendered badly in the screenshot, but after scrolling a single line, it would render okay, but "Pages" would not. ![Capture](https://user-images.githubusercontent.com/10236013/77794830-2afb2800-7032-11ea-9570-4441cae5f72c.PNG)

claunia commented