Replace SimSun, MingLiu, MSGothic, GulimChe with one (or four?) decent monospace fonts.

[bitcrazed]

From @be5invis on May 12, 2017 5:35

THEY ARE UGLY, REALLY.

The new font(s) should be:

• Exact half-width monospace, to prevent full-width glyphs being stretched or alignment being broken.
• No bitmap. In vector.
• Well hinted.
• Follows regional (CCJK) orthographic standards and aesthetic habits.

Copied from original issue: microsoft/WSL#2091

[bitcrazed]

From @SRGOM on May 15, 2017 10:53

I want this too but I highly doubt anyone would (or could) help you here. If you're looking for a font that works well in the X env, I doubt this team will tries to mess too much with the ubuntu userland. Even if they did, their expertise is very far from understanding fonts.

Outside X env, I doubt their team can touch much anway. This belongs to a different team.

I just noted that you're at MS yourself. It looks to me like you're closer to help solve this problem than anybody else. And while you're at it, can you have MS remove all the "Ming" fonts from the following: "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink"?

It's almost universally accepted that Ming fonts are not suitable for screen. So I would like them not being linked by default

[bitcrazed]

From @SRGOM on May 15, 2017 10:56

Oh, and while you're at it, can you ask MS to comission someone to make a good non-Ming font that covers CJK-ext-2?

Hanazono and MingLiu_HKSCS-ExtB both look horrible.

Thanks!

[bitcrazed]

From @zadjii-msft on May 15, 2017 16:47

@be5invis Hey, could you open a mail thread with richturn AKA @bitcrazed (he'll CC the rest of the team) on this? I'm sure we'd be more than happy to get some help getting better fonts in the console by default :)

[bitcrazed]

From @be5invis on May 15, 2017 17:32

@SRGOM Cover Ext BCD? This may take $10M and 5 years to make that font.

[bitcrazed]

From @SRGOM on May 29, 2017 4:39

@be5invis: I am not arguing with you, I'm only trying to understand- but do you guys not use Chise IDs or cjk decomposition or something similar for making fonts? In that case wouldn't the work be greatly reduced?

I know 42000 is a large number and I have no clue about how typefaces are designed but 15 expert-man-minutes for a symbol would give the impression that you manually-design every single symbol.

[bitcrazed]

From @be5invis on May 29, 2017 18:28

@SRGOM
Using IDS cannot create a typeface fitting the quality requirements of type designers. The parts will interfere so you cannot directly combine them together.

[be5invis]

@bitcrazed
Fixing this issue is basically to find a good, exact 1/2-em monospace font and make it the LGC part of a CJK font. Iosevka could be a choice, but the problem is that it cannot be "variable-font-ified" since it changes topologically when the weight changes.
Actions we could take:

• Adopt an open-source font — may need to resize the glyphs.
• Design a new one — needs some extra budget 💵💴.

[bitcrazed]

Thanks all for your comments.

We're very aware of the need to modernize & overhaul some of our fonts, especially SimSun, etc. Please bear with us while we work the process.

We also need to overhaul the Console's rendering technology to overcome its many limitations. We're developing a multi-release plan to solve this issue too.

[0xafbf]

Hello, today I discovered the SimSun font when changing the powershell font and I find it beautiful. It is a shame that there are no monospaced fonts with that level of detail, and SimSun cannot be used below size 14.
Patiently waiting here for some love to the console and the fonts.

[Mikhail22]

Started using the Terminal recently and came across this interesting discussion, just want to insert my opinions.

In terms of readability, best monospaced font (preinstalled with Windows) I've seen so far is SimSun. And Courier is not bad.
Though, both have common issue - originated from print typefaces, thus appear too thin on screen (unless theres some tricky hinting).

About SimSun:
It has better glyph proportions, Times-like (a bit narrowed, which is a plus) and details, but there are some glyphs not optimized for the monospace usage, e.g. glyhps "i", "l", "t" should have been morphed to cover more space, like in Courier. And most signs are centered to caps instead of being centers to lowercase letters, which is a drawback.

About Courier:
It has slightly better glyph spacing (see "i", "l"). I feel it is initially designed for monospace usage. But regardless, glyph proportions are too wide, and the design is on the 'grotesque' side which makes it less readable than SimSun.

So if I would do the job, I'd do following:

• take SimSun as a base
• make it slightly bolder (doing it properly in vector actually is long and painful story)
• center all signs to lowercase (><=*-{}[] etc.)
• work on some letters (i, l, t), i.e. make them wider, like in Courier

Also note that inter-line spacing affects readability, it would be nice to have an option to adjust the line spacing.

[bitcrazed]

Thanks for your feedback @Mikhail22 & @0xafbf

While we still have a lot of work to do, we've come a long way in the last year with the Terminal's new DirectX based text layout and rendering engine, UTF-8-aware text buffer, and other related features, including our new Cascadia Code monospace font.

We (Microsoft) also have work to do to overhaul some of our fonts, esp. for use in monospace environments in mixed Latin & non-Latin languages. Alas, font licensing, creation, hinting, etc. is a laborious, costly and complex subject area, but do know that we are working hard to figure out a decent story moving forward.

We do ask for your patience here though - this work will take some time.

[Mikhail22]

Thanks for yor comments @bitcrazed as well and good luck with the project!

Alas, font licensing, creation, hinting, etc. is a laborious, costly and complex subject area, but do know that we are working hard to figure out a decent story moving forward.

I dealt a lot with font related things, and I am curious about it.
BTW, I wonder why for this specific case (terminal) one would desire a vector font?
To my understanding, to make life easier, what one want is support for grayscale bitmap fonts aka 'graymaps'.

This would eliminate the pain of creating of fine fonts in the first place.
I would suggest to make the text renderer that can directly use bitmap font by specific sizes.
An example: to create graymaps for one size, Latin set, and to optimize it's quality/readability may take ca. 3 weeks of one man's work.
But creating a vector font, jiggling the vector paths and hinting may take 10x more time.
Especially trying to achieve the detail level and feel of a finely crafted font, it may take forever.

After all, it's only a question of scalability. In case of bitmap approach, I'd say creating 3-4 different sizes would cover most needs for 100-200 PPI displays. And for bigger sizes the renderer could just switch to some existing vector font, as it works now.

If it would be an open source font storage format, everyone could contribute fonts and edit them.
I could contribute to this too, especially to font design and composer algos.

[bitcrazed]

Trying to make a bitmap font that can scale correctly across the enormous gamut of screens and resolutions that we have to support in legacy, current, and future devices would be "difficult", to put it politely 😜

We prefer TrueType/OpenType vector fonts because they're scalable, adjustable, can be rendered by a GPU, etc.

Better still would be variable fonts defined by vectors at a few intermediate weights etc. that modern font engines can then interpolate-between to render at variable weights etc. But this requires more work (and thus cost and time) up-front.

Cascadia Code, gives you a good example of one of our most recently created, and open-source fonts, and for which we have bold goals. Eventually 😁

Now add to this the complexity of designing, creating, and defining the vector glyphs for CJK (Chinese, Japanese, and Korean) - this requires many thousands of glyphs to be defined. So many, in fact, that beyond the time & cost challenges mentioned above, physical factors including storage, memory, and runtime rendering considerations quickly come into sharp focus.

In addition, the font layout and rendering system has to be able to handle the various complexities of fitting complex glyphs into a grid - something that some letter/script forms do NOT easily support.

NOW add-in right-to-left (RTL) support too ... it all gets pretty complex pretty quickly. 😯

So we starting by trying to get Latins to work well. Then added more support for single-cell glyphs and emoji. Next, we'll continue to improve support for compound glyphs, and we'll start figuring out rules and rendering techniques for some of the more complex letter forms.

Again, this will take time and we appreciate the community's help by reporting issues in this repo so that we can catalog and fix issues over time.