Closed mqudsi closed 4 years ago
@miniksa is the guy who will know why this is happening.
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.
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.
Where can I get it and confirm the licensing?
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
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
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.
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?
I mean, there isn’t a font picker right now, so it isn’t showing anything?
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 :)
I think a good question is whether individual fonts within a family are looked up by their common name or their postscript name.
Also maybe related: #1163
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.
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
}
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.
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! 💪🏻
Another example
Victor Mono font (https://github.com/rubjo/victor-mono/)
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.
@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, 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.
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:
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
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'
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).
Running Windows Terminal (Preview) Version: 0.9.433.0
Cascadia Code PL 1911.21
Quick repro for me:
Install Fixedsys Excelsior (here)
Run CMD in WT
type <><>
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 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 The bug (behaviorally) is the small/wrong size. You're saying that Cascadia has a small glyph inside and that is wrong?
@shanselman Apologies for being unclear. I was referring to the color difference only. The size is almost certainly wrong.
I have a similar size issue with the Kubernetes Helm symbol ⎈ (U+2388) and the Fira Code font:
Good, good, y'all can head over to #900
This is in fact a bug submitted by @shanselman himself so 🤷♂
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 I'll help you via twitter, not in a GH issue
OK my issue is not related. I had downloaded the wrong font. Thanks @shanselman for the help.
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.
Caskaydia Cove
. And we've added some PL stuff to Cascadia itself. And the fact the emoji is small is just #900.@miniksa FYI the wonky icons comment was due to an uninstalled font
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.
@miniksa were you able to get around the fontWeight config var?
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":
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:
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:
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):