Several CJK strings on the UI are very difficult to read on standard definition monitors due to font weight and size

[Tyriar]

• VSCode Version: Code - Insiders 1.3.0-insider (a2b9738, 2016-07-01T19:24:33.352Z)
• OS Version: Linux x64 4.4.0-28-generic, Ubuntu 16.04

--locale=zh-CN bold in debug panel headings:

--locale=ko output panel title (it is 출 but it's awfully close to 춤 and 춥):

/cc @dbaeumer @bpasero @rebornix

[bpasero]

If this can be fixed by tweaking our CSS with some rules for CJK, we are good. Otherwise the bigger story is to support setting font from a setting. Moving to Brad first to see if we can fix this with some CJK CSS rules in the same way we do it here https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/electron-browser/media/shell.css#L20

[Tyriar]

How about something like this?

:root {
  --title-scale: 1em;
}
.monaco-shell:lang(zh-Hans),
.monaco-shell:lang(zh-Hant),
.monaco-shell:lang(ja),
.monaco-shell:lang(ko) {
  --title-scale: 1.2em;
}
.tiny-titles {
  font-size: var(--title-scale);
}

[bgashler1]

@Tyriar that's a cool way of making it bigger with CSS custom properties. @bpasero if you don't want to go that route, here is some regular CSS that would be equivalent.

.monaco-shell:lang(zh-Hans) .tiny-titles,
.monaco-shell:lang(zh-Hant) .tiny-titles,
.monaco-shell:lang(ja) .tiny-titles,
.monaco-shell:lang(ko) .tiny-titles {
  font-size: 1.2em;
}

Or a SASS approach, which works great if there a lot of other places that need to be addressed.

.monaco-shell:lang(zh-Hans),
.monaco-shell:lang(zh-Hant),
.monaco-shell:lang(ja),
.monaco-shell:lang(ko) {
  .tiny-titles {
    font-size: 1.2em;
  }
}

[bpasero]

I am very afraid of making such a change without sufficient feedback and testing from our CJK users. We never got this complaint from those users, so I would wait for sufficient number of people to complain.

As a reference, where I felt confident of doing a change: #5260

Maybe just get in contact with them to get an idea how bad it is.

We should not just fix CJK issues because we think they are issues for CJK users.

[Tyriar]

If English was that blurry and unreadable on the UI it would be a bug and an accessibility issue. Given the context, a user may know what it says naturally, but the text itself should be readable as a minimum for the sake of low-vision users. Also note that I can read Korean and basic Japanese and it's difficult/impossible to make out these characters. I cc'd @rebornix to get his thoughts on it too since he speaks Chinese.

[bpasero]

I wonder if in the end it would not be better to invest in a solution where the user can configure these things, either via settings or by being able to write CSS that gets injected.

[fantacytyx]

I am a Chinese user.
I found some parts of the Code use font sizes smaller than 12px
To better readability, font size need >=12px,if font size <=14px use normal font-weight is better.

[bgashler1]

Today in UX sync, we agreed to let this issue sit for a little bit to gather feedback from the community and to see if this affecting our users widely.

@Tyriar can you demonstrate with a GIF or some other instructions on how to change the font-size in Developer Tools for anyone interested in trying larger font sizes?

[bpasero]

👍 for asking feedback from CJK users. #5260 has a good list of people.

[Tyriar]

Sounds good.

It may be a good compromise if we didn't want to change the size of portions of the UI to just strip bold for Chinese, that way this (on Ubuntu):

Becomes:

That way at least some detail comes through in the last character.

[Tyriar]

If anyone wants to test out bigger/less bold titles on the sidebar you can add a style via devtools.

1. Help > Toggle Developer Tools

2. Add a new style rule by pressing the plus

   

3. Paste in this style:

   .monaco-workbench .viewlet .collapsible.header .title {
       font-weight: normal;
       font-size: 14px;
   }
   

[rebornix]

Here is my two cents:

• Font family is more important than font size. Currently we are using Segoe WPC, it's good enough but still far from perfect. If the font size is small, you have a difficult time to recognize the character. I'll put more info here after doing more investigation. If @bgashler1 wants to do any exploration, I can help on this.
• Big font size with normal font weight is better IMHO. There is a good UX blog about Chinese Font Best Practice which suggests use 10.5pt (I suppose it's 14px on web page).

Besides, there are two issue related to Chinese Fonts

1. The min-width of left side panel is too small.

   

2. Sometimes I use cmd++ to increase sizes of UI elements but the context menu doesn't change at all. See below, everything is bigger except the context menu

   

[Tyriar]

@rebornix looks like you're on a retina display too, so it is a lot better than a standard scale one, also the fonts selected probably differ across platforms, I was showing the one on Ubuntu.

[rebornix]

@Tyriar that's true, retina makes it better. If I plug in another Monitor with no 4k resolution, the characters are showing not that good.

Look at 量 next to 变, it's now a grey solid polygon.

[bpasero]

We did quite some tweaking on the selected font via #5260, I am surprised to hear that we still have font issues (related to the font family)?

[rebornix]

@bpasero let me correct my words, the fallback sequence of font-family with normal font-weight is perfect. From what I observe, the font-family that takes effect on a clean OSX is Hiragino Sans GB, but with bold font-weight, it looks worse than Helvetica or sans-serif. I'm not a Font expert so it may be just a weight issue :)

[Tyriar]

#5260 was about using the right glyphs for the right locale, not about optimizing for legibility.

[be5invis]

@rebornix
Your image looks strange, PingFang SC is not that bold. Have you installed Office? In the fallback sequence I suggested, following the sequence used for Latin, Microsoft YaHei has a higher priority.
PingFang SC does not have a proper Bold weight, but I am not sure whether this affects the fallback behavior.

Perhaps the fallback sequence can be improved into:

• For zh-CN : font-family: "Segoe WPC", "Segoe UI", -apple-system, BlinkMacSystemFont, "SFUIText", "Helvetica Neue", "Noto Sans", "Microsoft YaHei", "PingFang SC", "Hiragino Sans GB", "Source Han Sans SC", "Source Han Sans CN", "Source Han Sans", sans-serif
• For zh-TW : font-family: "Segoe WPC", "Segoe UI", -apple-system, BlinkMacSystemFont, "SFUIText", "Helvetica Neue", "Noto Sans", "Microsoft Jhenghei", "PingFang TC", "Source Han Sans TC", "Source Han Sans", "Source Han Sans TW", sans-serif
• For ja : font-family: "Segoe WPC", "Segoe UI", -apple-system, BlinkMacSystemFont, "SFUIText", "Helvetica Neue", "Noto Sans", "Meiryo", "Hiragino Kaku Gothic Pro", "Source Han Sans J", "Source Han Sans JP", "Source Han Sans", "Sazanami Gothic", "IPA Gothic", sans-serif
• For ko : font-family: "Segoe WPC", "Segoe UI", -apple-system, BlinkMacSystemFont, "SFUIText", "Helvetica Neue", "Noto Sans", "Malgun Gothic", "Nanum Gothic", "Dotom", "Apple SD Gothic Neo", "AppleGothic", "Source Han Sans K", "Source Han Sans KR", "Source Han Sans", "UnDotum", "FBaekmuk Gulim", sans-serif

(preserving the current Windows — Mac — Linux sequence)

Perhaps @Tyriar can consider using weights like 600 to select a slightly thinner variant on CJK locales.

[be5invis]

@Tyriar
Rasterization of Kanji and Hangul is extremely hard, especially on small sizes (like 12ppem). To be clear you need a special font with a lot of additional data (gridfits, in detail) to tell the rasterizer how to distort the outline to make the characters’ shape legible.
I have made a font called Inziu, and that one contains such data (which takes about three hours to compute out), but some rasterizers may IGNORE them, like Mac OS.

[rebornix]

@be5invis My OS is OSX 10.10.5 and yes I've Office 2010 for Mac installed. The funny thing is the Font Family that takes effect is Hiragino Sans GB, which look badly in bold. Not sure whether I miss any System update or not :)

[bgashler1]

UX Meeting Summary:
We will remove all bold font-weight from the CJK characters as a first step.

This occurs in only a few places. This should solve the issue for many people. It’s possible those with lower-dpi monitors or other factors (potentially operating systems with different fonts or font-rendering algorithms) will need us to take an additional step. We can make this initial change on Insiders build and leave the issue open for further feedback. We then can take further action, if needed from there.