Typography tune-up needed

[bgashler1]

On VS Code for Mac, Windows and Linux we're using system fonts to fit in with the OS.

TODOS:

Apply OS-specific guidelines on typography for optimal legibility and visual consistency
https://developer.apple.com/ios/human-interface-guidelines/visual-design/typography/
https://msdn.microsoft.com/en-us/windows/uwp/style/typography

Ensure a consistent visual hierarchy, and check consistency in
Font-weight
Font-size
Line-height
Using the font features as typeface intends (tracking, kerning, anti-aliasing).

Mac feedback

Some feedback from our users

• Seems overweighted

Some feedback from users of other products who use San Fransisco in Chrome

• Chrome appears to have less characters per line (tracks differently) than Safari.
• Characters stand out more than words (tracking issue in Chrome)
• Abrupt change, takes some getting used to.

[bpasero]

@joaomoreno fyi

[joaomoreno]

AFAIK, the font is what Apple recommends for small type. #9055

[brunnopleffken]

San Francisco seems to have a quite large letter spacing in Chromium when using the system font alias as font-family, leaving this "cluttered" feeling of the UI.

I found that instead of BlinkMacSystemFont (-apple-system is useless in Visual Studio Code as it doesn't target Chromium, only Safari and iOS), using '.SFNSDisplay-Regular' seems to solve. It uses exactly the same San Francisco Display family and there's no kerning or letter spacing issue; and this without changing the font weight or size.

With this fix, letter spacing and kerning of SF will look like the same as using Segoe UI in Windows, or Ubuntu in... well... Ubuntu, or Helvetica Neue in OS X Yosemite, giving us a much better feel!

[fitojb]

Please use Display only for display sizes (e.g., large headings), but not for regular UI copy, where it isn’t appropriate. Let Chromium/Electron fix their spacing issue.

[brunnopleffken]

I strongly disagree @fitojb. This is a recent issue, they're still tracking it and trying to find a way to solve it as you can see in their forums (it's not an Electron issue, it also affects Google Chrome and Opera), so just sounds like "we will use this feature and wait for the vendor to fix it". Is just counter-productive! So isn't also appropriate "downgrade" to Helvetica Neue until the issues with San Francisco's kerning/letter space rendering are fixed? Otherwise feels like the UI font is Verdana or any other wide typography! In a sidebar, with lots of files and folder names, in my exp., I have to make it even wider (= less area to code) in my MacBook 13".

In the mid-2010's we learned that typography is everything! BTW, this is not a website, is a software, currently it just doesn't fit well with the UI and, IMHO, it just doesn't fit in a code editor that is filled with lot of information all the time!

[wprater]

a quick fix for macOS seems to be applying -webkit-font-smoothing: antialiased; to the editors content or the whole UI.

[brunnopleffken]

@wprater But this will also remove the subpixel antialiasing in non-Retina displays (low-DPI screens), which is undesirable.

[wprater]

ahh, thanks for the note about that.

can't we just use a media query to select on the pixel density?

Implementing #459 to allow for fine grained control would be helpful too.

[wprater]

we can use a query like this to set the font-smoothing. probably only need to use the min-resolution tho

@media 
(-webkit-min-device-pixel-ratio: 2), (min-resolution: 192dpi) { 
    /* Retina-specific stuff here */
}

Would it be suitable to add something like this to a PR? I'd love to see crisper fonts all around.

[bgashler1]

@wprater if you can verify this improves hdpi screens and doesn't negatively affect regular screens, this would be a great PR. Thanks! We will need to test it on Linux, Windows and Mac hdpi screens to verify before merging into master.

[brunnopleffken]

@wprater @bgashler1
Whatever you do to the high-DPI screens (propably you're talking about the -webkit-font-smoothing: antialiased trick), be aware that this should apply ONLY to the dark theme, as applying to the light theme will make the font rendering appear WAY TOO thin, making it really difficult to read!

TextMate also does this distinction when changing between light and dark themes.

[wprater]

Whatever you do to the high-DPI screens (propably you're talking about the -webkit-font-smoothing: antialiased trick), be aware that this should apply ONLY to the dark theme, as applying to the light theme will make the font rendering appear WAY TOO thin, making it really difficult to read!

I applied it to all the themes, looks much better to me. However, I assume this could be subjective and will leave it up to others to help determine how/if we should apply the change. Its easy enough to restrict to each theme type (dark, light, hc).

/cc @brunnopleffken

[syabro]

You can add

body {-webkit-font-smoothing: antialiased;}

to

/Applications/Visual\ Studio\ Code.app/Contents/Resources/app/out/vs/workbench/electron-browser/workbench.main.css

[agauniyal]

On my system (Linux) the fonts appear to be thinner on vscode than chrome would display them.

[stevencl]

You'll have a better idea about what we might want to do here @misolori.

[brunnopleffken]

Wow, it's been a long time since this issue was created! Well, actually this issue is a Chromium bug with CoreText that was fixed in Chrome 64.0.3258.0: "Fix tracking for Mac system fonts" (487f920d...).

AFAIK, VSCode still uses Chrome 61, so the kerning of San Francisco font family is still broken. There's no need to fix or workaround it on VSCode itself, basically and updated version of Chromium should fix this issue, making the rendering of SF looking amazing like on Safari.

[bpasero]

@brunnopleffken we have builds up and running with Chrome 66 if you want to test it out:

Download:

• macOS: Download
• Linux: Download
• Windows: Download

[brunnopleffken]

Just tested VSCode Exploration with Electron 3.0/Chrome 66 and there are differences to font rendering. As Chrome 64 fixes the kerning of San Francisco fonts using macOS' CoreText, the dots and dashes, letters like T, V, A, W uses the correct kerning and are readable as the native UI (seems less "monospaced"). I made a diff:

(Chrome 66 is magenta; the old Chrome 61 is lime)

[fitojb]

Thanks for properly waiting for Chromium to properly fix the issue instead of introducing ridiculous workarounds downstream (like using display fonts for body text)!

[miguelsolorio]

@bpasero what are our current plans for upgrading to Chrome 66?

[bpasero]

@misolori this year is all I can predict

[jkyeung]

Thank you to all the contributors in this thread! The fact that there are other people who care enough about font rendering to make this an actual issue is very reassuring.

Thanks especially to @bpasero for the link to the Chrome 66 build and @brunnopleffken for testing.

I can confirm that the Chrome 66 build makes a difference. I've been trying to tweak the kerning of a font using FontForge on Windows 7, and it was really frustrating that some of my changes were showing up but some weren't (in the mainstream VS Code build). As a total noob to font editing, I would have assumed it was just me not knowing how to use FontForge properly, but when I used the same modified font in another editor (SciTE), all my kerning changes did show up. So I went looking for VS Code issues, and fortunately found this one. The VS Code exploration build renders all my kerning changes as I intended them.

Update:
Spoke too soon. :( The Chrome 66 build does render more of my changes, but still not all of them.

Further update:
Evidently "syntax highlighting boundaries" come into play. I'm using this font in the main editing window. In both builds, VS Code will do all my kerning as long as both characters in the pair are within strings. Chrome 66 will kern my (right paren, comma) pair even when they are not in a string (i.e. they are actual punctuation in code) but Chrome 61 will not. Neither one kerns my (quote, comma) pair if the quote ends a string and the comma is just outside the string (which for me means they are different colors).

So... is what I'm describing a VS Code issue after all? Or is it still upstream? Should I open a new issue?

[daviddossett]

@bgashler1 I'm doing some housekeeping—is this still a relevant issue? I know there has been a ton of changes in the last six years so I don't have a good sense of the delta from 2016 to now.

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[bgashler1]

@daviddossett I'm not sure. A lot has changed in the product and Electron's Chromium renderer since when I created this. At the time, we had some weird tracking issues in some platforms, but I haven't noticed them lately. Probably good to close the issue—as has been done already—and open new issues as needed.