microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.09k stars 8.24k forks source link

Font rendering issues in Terminal #610

Closed mqudsi closed 4 years ago

mqudsi commented 5 years ago

I have Terminal up and running under 18362.0, but it seems to have problems with certain types of fonts.

Here it is working fine with the font set to "SF Console":

image

But it breaks when the font is changed to "SF Console Medium" (but not because the font isn't found or anything). The app doesn't crash but the text is rendered... let's just say extremely incorrectly:

image

If you focus extremely well and zoom in all the way, you can see that text is being rendered.. just very oddly so. Change the font back and it redraws correctly to what it used to contain.

Here's the same screenshot from conhost with the font set to "SF Console Medium" via the registry:

image

It's not just an issue with setting a variant of a font, or this particular font. Here's how the default (free) "Roboto Slab" is rendered, but I'm not sure if it's the same problem (it doesn't look like it):

image

zadjii-msft commented 5 years ago

@miniksa is the guy who will know why this is happening.

miniksa commented 5 years ago

Is "SF" the San Francisco font from Apple that we're absolutely not authorized nor licensed to use outside of an Apple computer?

If so, I can't investigate this and have to slam it closed. I can't debug/diagnose fonts I'm not licensed to use and I can't condone having other people break that license agreement.

mqudsi commented 5 years ago

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.

miniksa commented 5 years ago

Where can I get it and confirm the licensing?

mqudsi commented 5 years ago

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

miniksa commented 5 years ago

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

iKlsR commented 5 years ago

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.

mdtauk commented 5 years ago

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?

DHowett-MSFT commented 5 years ago

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

mdtauk commented 5 years ago

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 :)

mqudsi commented 5 years ago

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

zadjii-msft commented 5 years ago

Also maybe related: #1163

vsalvino commented 5 years ago

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.

bmo-at commented 5 years ago

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
        }
miniksa commented 5 years ago

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.

bmo-at commented 5 years ago

image 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! 💪🏻

offero commented 5 years ago

Another example

image

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

BinaryInk commented 5 years ago

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

danieldjewell commented 4 years ago

@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
miniksa commented 4 years ago

@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.

horseinthesky commented 4 years ago

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

Here is how it should look like: image

MartinSGill commented 4 years ago

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

image

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

Font in this case is Fura Code NF

austinwagner commented 4 years ago

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

johnwildes commented 4 years ago

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

image

Running Windows Terminal (Preview) Version: 0.9.433.0

Cascadia Code PL 1911.21

DHowett-MSFT commented 4 years ago

Quick repro for me:

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

image

shanselman commented 4 years ago

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

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

image

austinwagner commented 4 years ago

@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.

shanselman commented 4 years ago

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

austinwagner commented 4 years ago

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

gitfool commented 4 years ago

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

image

DHowett-MSFT commented 4 years ago

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

DHowett-MSFT commented 4 years ago

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

calloncampbell commented 4 years ago

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

shanselman commented 4 years ago

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

calloncampbell commented 4 years ago

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

sergio-u commented 4 years ago

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

miniksa commented 4 years ago
XzAeRo commented 4 years ago

@miniksa FYI the wonky icons comment was due to an uninstalled font

miniksa commented 4 years ago

With the completion of this checklist: https://github.com/microsoft/terminal/issues/610#issuecomment-618068103, I am deeming this bug closed and resolved by other issues on the tracker. Thanks. Please file new issues against the latest version if there are still problems not addressed or covered by the open #900 or #455.

tm9k1 commented 4 years ago

@miniksa were you able to get around the fontWeight config var?