Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use system-ui alias for UI fonts (fixes #10144) #96948

Merged
merged 1 commit into from
May 8, 2020
Merged

Use system-ui alias for UI fonts (fixes #10144) #96948

merged 1 commit into from
May 8, 2020

Conversation

kdrag0n
Copy link
Contributor

@kdrag0n kdrag0n commented May 4, 2020

This PR fixes #10144.

Commit 45d93e9 applied this change in some areas, but it was reverted to fix #28619. The underlying cause of the regression was Chromium bug 733219, which has now been fixed, so this change should be safe to apply now.

The old font stacks have been kept with lower priorities to work around Chromium bug 724393.

Commit 45d93e9 applied this change in
some areas, but it was reverted to fix #28619. The underlying cause of
the regression was Chromium bug 733219 [1], which has now been fixed, so
this change should be safe to apply now.

The old font stacks have been kept with lower priorities to work around
Chromium bug 724393 [2].

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=733219
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=724393
@bpasero bpasero added this to the On Deck milestone May 6, 2020
@bpasero bpasero requested review from joaomoreno, Tyriar, bpasero and mjbvz May 6, 2020 07:13
@bpasero
Copy link
Member

bpasero commented May 6, 2020

Adding a couple more eyes to review this. Especially @Tyriar as the one that merged #25570 should have a saying in this too.

My understanding is that this still would only impact Linux, but not Windows and macOS?

@joaomoreno joaomoreno requested a review from miguelsolorio May 6, 2020 11:28
Copy link
Member

@joaomoreno joaomoreno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works fine on my Windows box.

@bpasero
Copy link
Member

bpasero commented May 6, 2020

Thanks @joaomoreno. I can test on macOS, maybe Daniel could on Linux.

Copy link
Contributor

@miguelsolorio miguelsolorio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested this on macOS Catalina and didn't see any differences, even when overlaying the two:

Left: This branch, Right: Current Insiders
image

@bpasero bpasero requested a review from alexdima May 7, 2020 08:57
@bpasero
Copy link
Member

bpasero commented May 7, 2020

Adding @alexdima given there is a change to Default standalone editor font

@bpasero
Copy link
Member

bpasero commented May 7, 2020

@kdrag0n I am worried when I see reports (even though a bit dated) about not using system-ui such as:

What can you say about the claim it will regress for users with non-us locale?

@kdrag0n
Copy link
Contributor Author

kdrag0n commented May 8, 2020

I just set the system language to Chinese on my Windows VM and this change actually appears to improve consistency.

Before:
image
Notice how the English font used in VS Code doesn't match Explorer, and the line height is different from the Chinese font. The height mismatch is especially evident in the menu mnemonics at the top, but it also shows in the "Help" section.

After:
image
With system-ui, VS Code's font looks more like Explorer and the English text looks more like it's a part of the Chinese text rather than being shorter.

The system-ui font can also be seen in Chrome's context menus:
image

And Explorer:
image

@bpasero
Copy link
Member

bpasero commented May 8, 2020

There was also this user on Windows (#25570 (comment)) that reported bad results when we added system-ui as first font to pick. I am worried that we could get more users on Windows seeing a font that is different so I suggest we scope this change to Linux only. Does that make sense?

@kdrag0n
Copy link
Contributor Author

kdrag0n commented May 8, 2020

The problem with #25570 was the removal of all the other fonts, caused by Chromium bug 724393 which is marked as wontfix. That's why I kept the old font stack after system-ui — it was cited as the fix for that issue in #26912.

I'm fine with limiting this change to Linux since that's where it affects me, but it's nice to be consistent across platforms in case someone wants to change the system font on another OS. Even without a custom system font, using system-ui on Windows helps fix the wrong font being used for Latin characters if the language is set to Chinese, as I demonstrated above.

I suspect there are probably similar cases of this fixing incorrect fonts with other languages and possibly even on macOS, though I haven't tested that.

@bpasero bpasero merged commit ff11834 into microsoft:master May 8, 2020
@bpasero
Copy link
Member

bpasero commented May 8, 2020

Let's roll with it in insiders and gather more feedback. I am merging this in given prior approval by people in #25570 which is essentially the same change.

@kdrag0n kdrag0n deleted the system-ui-font branch May 13, 2020 05:43
@fireattack
Copy link

Unfortunately, that issue mentioned in #25570 (or similar) still exists on non-English systems.

Setup: Win7 x64 Simplified Chinese system.

image

All the words are in proper English fonts.

image

All the words are in MS Yahei (default Chinese font for Simp. Chinese Windows), which is not optimal for displaying English.

(I use English UI to demonstrate the issue better. The same issue exists on Chinese UI too as soon as there are English letters.)

In general, I don't think using system-ui on Windows is a good idea, for the reasons stated in https://infinnie.github.io/blog/2017/systemui.html.

@bpasero
Copy link
Member

bpasero commented Jun 2, 2020

@kdrag0n ?

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 3, 2020

The new font is different, but according to what I saw when testing on a Chinese Windows 10 system, the new font is more correct. The old font was different from the English UI font used in the rest of the system, which changed when I set the language to Chinese. Are you sure that this isn't the case on Windows 7?

@fireattack
Copy link

fireattack commented Jun 3, 2020

I believe what you described is exactly the case for both Win 10 or Win 7; if you use "system-ui", it will apply a Chinese font (MS YaHei) to all the glyphs, which is not optimized for Latin letters.

Yes, it is the default font for Windows in Chinese locale, but no one likes it for displaying Latin letters and it shouldn't be used on anything but Chinese characters.

Just to make it clear, this is not just my personal opinion, more or less an industry consensus. Please check the details in https://infinnie.github.io/blog/2017/systemui.html and why GitHub and Bootstrap along with batch of other major websites removed "system-ui" from their font stack.

This is a Windows only issue. The root cause is it doesn't use fallback to display UI like Mac OS (twbs/bootstrap#22328 (comment)) to ensure both Latin and Chinese characters look good. So by all means use "system-ui" on Linux, just like -apple-system on Mac. But not on Windows. If we want a catch-all-rule (doesn't seem necessary since we can define font stack for each OS already), putting it like "Segoe UI", system-ui, in this order. This would optimize the Latin letters on Windows with Segoe UI, while the Chinese characters will still fall back to a proper Chinese font (without affecting other OS since they don't have Segoe UI installed).

At the very least, the Chinese font should never be used if the user is deliberately using English UI, like I showed above. This is not just about look and feel, but functionality: these Latin letters in those Chinese fonts are often wider, which cause the text to overflow all over the places. Probably less an issue for VS Code, but it has been a long-standing problem for any program that doesn't test with non-Western locales since Windows 9X.

Feel free to ask some i18n experts from MS team for their insight, if above is not convincing.

@bpasero
Copy link
Member

bpasero commented Jun 4, 2020

If that is the consensus, maybe another PR could be made for Windows only. Happy to review.

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 4, 2020

I checked Bootstrap's current font stack and it looks like they brought system-ui back in twbs/bootstrap#30561.

I'm still not entirely convinced about the Windows Chinese font issue because I think that apps should respect the system conventions whenever possible, even if it might not be the best option in the app developer's opinion. Inconsistent fonts (and mismatching line heights for CJK fonts, which can be distracting when reading mnemonics in menus) can be quite annoying. For example, in the blog post linked above, the system-ui font is used in the Chrome UI:
image

It's clearly not the best font for that content, but it is consistent with the rest of the system.

As far as I can tell, there's no instances of text overflow in VS Code either when using Microsoft YaHei for the UI.

However, if this change is to be reverted for Windows, adding Segoe UI before system-ui would cause problems on Linux and macOS systems that happen to have Segoe UI installed — this already introduces some inconsistency for me with the old font stack, where most of the UI is using Ubuntu but some parts are using Segoe UI.

This is especially an issue when it comes to the components that have fonts set by TypeScript code rather than CSS, e.g. VCS commit message editor and Markdown preview, as it's harder to use different font stacks based on the OS in those cases.

I'm not sure what the best way to proceed is in this case, considering consistency with the rest of the system vs. how the font looks when rendering Latin text. @bpasero thoughts?

@fireattack
Copy link

fireattack commented Jun 4, 2020

it looks like they brought system-ui back in twbs/bootstrap#30561.

I tested 4.5.x before posting, didn't notice they changed it later. Sorry! But their wording there (twbs/bootstrap#30561 (comment)) doesn't sound to me they actually tested that i18n issue brought by a dev.

the system-ui font is used in the Chrome UI

Chrome must have changed that too. This is what Simp. Chinese Chrome in Simp. Chinese Windows looks like:

image

You can see the font for Latin letters on tab is clearly not MS Yahei.

I checked some UI elements and this is what they use:

image

cause problems .. that happen to have Segoe UI installed

I agree. If we can do so per OS there is no need for such workaround.

I get your point of consistency and understand that's also important. But I think at the very least, the UI shouldn't be in a Chinese font if a Western display language is chosen in VS Code, just because the user is using a Chinese OS.

@bpasero
Copy link
Member

bpasero commented Jun 4, 2020

@kdrag0n

Can we not simply change the rule from:

font-family: system-ui, -apple-system, BlinkMacSystemFont, "Segoe WPC", "Segoe UI", "Ubuntu", "Droid Sans", sans-serif;

to

font-family: -apple-system, BlinkMacSystemFont, "Segoe WPC", "Segoe UI", system-ui, "Ubuntu", "Droid Sans", sans-serif;

My understanding is that:

  • -apple-system, BlinkMacSystemFont are ignored on Linux, Windows
  • "Segoe WPC", "Segoe UI" are ignored on Linux, macOS
  • system-ui will be picked up by Linux distros

Wouldn't this solve the original intent of fixing the font stack on Linux? It would not change a lot for Windows I guess, but given there seem to be issues, maybe we shouldn't try to solve it.

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 4, 2020

"Segoe WPC", "Segoe UI" are ignored on Linux, macOS

As I said in my previous comment, this can cause issues on other OSes:

Adding Segoe UI before system-ui would cause problems on Linux and macOS systems that happen to have Segoe UI installed — this already introduces some inconsistency for me with the old font stack, where most of the UI is using Ubuntu but some parts are using Segoe UI.


What do you think about the fix in https://github.com/kdrag0n/vscode/commit/91ac1372c4c0e8bce6ff3d2ab50d635a44b5524c? I haven't tested it myself, but it's similar to what @fireattack suggested above and it appears to be a reasonable compromise while avoiding issues on other setups. Let me know if you want me to create a new PR for it.

@bpasero
Copy link
Member

bpasero commented Jun 4, 2020

@kdrag0n sorry I am confused now, my suggestion was to add system-ui AFTER Segoe not before. In essence this should really only have an impact on Linux.

Yes, the fix you linked to seems going into the right direction, however this PR changed the font in many more places, some of them have no notion of OS. Hence my suggestion to fix it for all OS given the suggestion I made.

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 4, 2020

The problem with putting system-ui after Segoe UI is that Linux or macOS systems can have Segoe UI installed. While that font is typically only found on Windows systems, it is still possible to install on other OSes and this can be useful in many cases, e.g. creating mockups.

I believe that changes would need to be made to the TS code and the CSS selectors in other places to fix the issue for all possible setups.

@bpasero
Copy link
Member

bpasero commented Jun 4, 2020

@kdrag0n I understand, but isn't the presence of the Ubuntu font on a non-Ubuntu distro a good indication that maybe that font should be used?

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 4, 2020

Not really. Many Linux users (myself included) aren't using Ubuntu and have the Ubuntu font installed for one reason or another, but that doesn't mean it should be used. On Linux, the UI font is customizable and there are many people who do change it, so VS Code should respect the user's choice. It's one of the only apps on my system that ignores my preferences and chooses to use a different font. That's the reason I opened this PR in the first place: to fix the font disparity and use the correct font. It's hard to generalize OSes and use a single font stack for all of them because of the Windows CJK issue, so I think the only option is to make the other places OS-dependent as well.

I'm not entirely sure whether this is the case, but one plausible out-of-the-box example is Kubuntu where the Ubuntu font would be installed because it's a Ubuntu-based distro, but the UI font would be set to Noto Sans as per KDE's defaults.

@bpasero
Copy link
Member

bpasero commented Jun 5, 2020

@kdrag0n given we do not have platform specific rules in some places, why can we not do this rule instead, putting system-ui after Segoe:

-apple-system, BlinkMacSystemFont, 'Segoe WPC', 'Segoe UI', system-ui, 'Ubuntu', 'Droid Sans', sans-serif

My understanding:

  • macOS: is not impacted, -apple-system, BlinkMacSystemFont takes care of that
  • Windows: is not impacted, Segoe is winning
  • Linux: should only be impacted if Segoe is actually installed, but will prefer a native Linux font over Ubuntu

So this would only cause issues if someone installed Segoe intentionally, but even in that case today already VSCode would pick this font up.

@kdrag0n
Copy link
Contributor Author

kdrag0n commented Jun 5, 2020

Yes, that would work fine for most setups, except Linux systems that have Segoe installed. That's one of the problems that I originally intended to solve with this PR as I'm seeing both inconsistent (Segoe) and non-native (Ubuntu) UI fonts with the old font stacks. If your proposed umbrella stack is used in other places, the Segoe inconsistency issue would come back and some Linux users would see inconsistent fonts again — the very issue that this was supposed to fix.

Again, I don't see any way to fix this issue everywhere unless the other places are updated to add platform-specific stacks (or unify all/most of the scattered stacks into one somehow to reduce maintenance costs) because system UI fonts are an inherently platform-specific detail.

@bpasero
Copy link
Member

bpasero commented Jun 5, 2020

@kdrag0n upon closer looking, it seems to me we are already inconsistent given that our platform rules for the workbench define a different font stack compared to those places where we have the combined font stack:

.mac { font-family: system-ui, -apple-system, BlinkMacSystemFont, sans-serif; }
.mac:lang(zh-Hans) { font-family: system-ui, -apple-system, BlinkMacSystemFont, "PingFang SC", "Hiragino Sans GB", sans-serif; }
.mac:lang(zh-Hant) { font-family: system-ui, -apple-system, BlinkMacSystemFont, "PingFang TC", sans-serif; }
.mac:lang(ja) { font-family: system-ui, -apple-system, BlinkMacSystemFont, "Hiragino Kaku Gothic Pro", sans-serif; }
.mac:lang(ko) { font-family: system-ui, -apple-system, BlinkMacSystemFont, "Nanum Gothic", "Apple SD Gothic Neo", "AppleGothic", sans-serif; }
.windows { font-family: system-ui, "Segoe WPC", "Segoe UI", sans-serif; }
.windows:lang(zh-Hans) { font-family: system-ui, "Segoe WPC", "Segoe UI", "Microsoft YaHei", sans-serif; }
.windows:lang(zh-Hant) { font-family: system-ui, "Segoe WPC", "Segoe UI", "Microsoft Jhenghei", sans-serif; }
.windows:lang(ja) { font-family: system-ui, "Segoe WPC", "Segoe UI", "Yu Gothic UI", "Meiryo UI", sans-serif; }
.windows:lang(ko) { font-family: system-ui, "Segoe WPC", "Segoe UI", "Malgun Gothic", "Dotom", sans-serif; }
.linux { font-family: system-ui, "Ubuntu", "Droid Sans", sans-serif; }
.linux:lang(zh-Hans) { font-family: system-ui, "Ubuntu", "Droid Sans", "Source Han Sans SC", "Source Han Sans CN", "Source Han Sans", sans-serif; }
.linux:lang(zh-Hant) { font-family: system-ui, "Ubuntu", "Droid Sans", "Source Han Sans TC", "Source Han Sans TW", "Source Han Sans", sans-serif; }
.linux:lang(ja) { font-family: system-ui, "Ubuntu", "Droid Sans", "Source Han Sans J", "Source Han Sans JP", "Source Han Sans", sans-serif; }
.linux:lang(ko) { font-family: system-ui, "Ubuntu", "Droid Sans", "Source Han Sans K", "Source Han Sans JR", "Source Han Sans", "UnDotum", "FBaekmuk Gulim", sans-serif; }

Maybe I can get the platform differences into the other places too.

Btw on Windows we already have different fonts if your locale is zh-Hans, zh-Hant, ja or ko. I think you mentioned that for those, picking system-ui is a better fit over Segoe, so we could leave system-ui in front for those at least.

@fireattack
Copy link

fireattack commented Jun 5, 2020

for those, picking system-ui is a better fit over Segoe

I think you got it backwards. Having Segoe in front of system-ui in these locales can ensure the Latin letters are in Segoe while the CJK characters still fall back to system fonts because Segoe doesn't have these glyphs.

Actually, as you can see here, since corresponding system font is already in the rule ("Microsoft YaHei" for zh-Hans for example) after Segoe, there is no need for "system-ui" at all.

Same goes to Western locales: the system-ui is already Segoe.

To summarize: system-ui isn't needed on Windows at all, and putting it in front of Segoe cause harm on zh/ja/ko locales, which is exactly why we had things like "Segoe WPC", "Segoe UI", "Microsoft YaHei" (in this order) before.

@bpasero
Copy link
Member

bpasero commented Jun 5, 2020

@kdrag0n @fireattack I tried my best in #99429 please take a look.

@fireattack
Copy link

Looks good to me, will test once it launched on Insider.

@bpasero
Copy link
Member

bpasero commented Jun 6, 2020

@fireattack we have since released a new insiders with these changes

@fireattack
Copy link

fireattack commented Jun 6, 2020

Just tested, it looks good in both Simplified Chinese and English on my Simplified Chinese Windows.

image

image

Thanks!

(Just a side note: if you look carefully, you will find that some formatted strings are not displayed correctly when using zh-cn display language.

仅当 "#files.autoSave#" 设置为“afterDelay”时才适用。

Both the anchor and the monospace parts are not displayed correctly.

But this is unrelated to this patch, it has been like this for a long time.)

@bpasero
Copy link
Member

bpasero commented Jun 7, 2020

Thanks for taking the time to test this 👍

@github-actions github-actions bot locked and limited conversation to collaborators Jun 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Text disappeared after update to 1.13 [Bug] Use system-ui as font on Linux
6 participants