Cascadia Next SC, TC, and JP

[nguyen-dows]

We would like to introduce the next evolution of the Cascadia font family, Cascadia Next.
Our talented typographer @aaronbell has created three variants of Cascadia Next for SC (Simplified Chinese), TC (Traditional Chinese), and JP (Japanese)

This pre-release contains limited character sets that cover a vast majority of use cases for these languages.

Note that this pre-release does not contain Arabic, Hebrew, or NerdFonts support.

Please try these fonts out! (Especially those who use SC, TC, and JP text in their terminals!)
We would love to hear your feedback! 😊

---

This discussion was created from the release Cascadia Next SC, TC, and JP.

[Yue-plus]

Do not support Ligatures / 不支持连写

Glad to see nice Chinese and English equal width font! I've already used this font in terminals and VS Code.
很高兴看到好看的中英文等宽字体！我已经在终端和 VS Code 中使用了该字体。

Look forward to supporting Ligatures in the future.
期待未来能够支持连字功能。

Cascadia Next SC

Cascadia Code

[aaronbell]

Yes, this is a beta release ahead of the full re-work of the font / build system. Glad you're enjoying the font so far!

[yoruritchie]

I feel that the Cascadia Next font looks thinner.

[Jacquwes]

I feel that the Cascadia Next font looks thinner.

I think it's to make the font weight more consistent with the Chinese characters.

[aaronbell]

In considering the existing Cascadia Code, I've felt that the current Regular weight is a little too dark. So in deciding how to move forward with Cascadia Next, I decided to lighten the font a bit. And the CJK forms were weighted to align with them.

[madig]

Cool! Is there a brief somewhere for what "Next" is going to be about and how it will differ from "Code"?

[aaronbell]

I’ve written a number of thoughts down but haven’t announced anything final.

To summarize briefly my ideas:

1. new build system to allow for language specific builds of Cascadia and keep file size minimal.
2. complete rework of the OT feature functionality to enable better customization and new features
3. new width axis for narrower setting
4. switching to 2 masters only and repositioning Regular to SemiLight 🫣

Needless to say, when I put all the ideas together, it didn’t make sense to break everything in the existing Cascadia project and better to move towards a fresh version.

[madig]

Thanks :) Which build system are you using? Is going for 2 masters gonna preserve design detail across the axes? I imagine compromises have to be made 🫠

[aaronbell]

TBD. Either one based on Google's Makefile build system, or another that is soon to be released.

Actually, the two master set up isn't bad in this case. The design itself is fairly straightforward, and the weight axis is only Light to Bold, so we don't see the usual kinds of shenanigans common with the extremities. When I did a quick comparison of the old Regular to the interpolated version at the same location, I found the differences to be pretty minimal and well within tolerance.

[KexyBiscuit]

Looks good, except I don't know the reason that I can't use the font in Photoshop... It just doesn't appear in the list.

[aaronbell]

Hm. Not sure why that would be the case. Are you able to use the font elsewhere?

[KexyBiscuit]

Hm. Not sure why that would be the case. Are you able to use the font elsewhere?

Yes, the font appears in Acrobat and nearly all other applications, just not in Photoshop. Tested on both Windows and macOS.

[aaronbell]

Hm. The fonts lack a STAT table, but that shouldn't stop them from working in Photoshop, unless it relies on that table to enumerate the fonts in the menu...

I'll make sure to add it in with the next version

[aaronbell]

We've updated the fonts in the beta release with a corrected STAT table, if you'd like to try it out 😄

[hooke007]

If you could provide another variant of merging cjk, it would be useful.

[heartacker]

yes, that would be great

[aaronbell]

What do you mean?

[KexyBiscuit]

What do you mean?

Maybe Cascadia Next, Latin + SC + TC + JP in one ttf/otf file?

[aaronbell]

Ahh I see. I’ll have to consider if that is viable given the character counts.

[heartacker]

the next font is thinner than ever before, could you please make it A little wider

[aaronbell]

@mdtauk the width axis will not apply in CJK to start as there are not narrower versions of the CJK forms.

[heartacker]

I believe he mean the width-to-height ratio. Before it was around 1200:2048 (58.5%), in the Next font it is 500:1000 (50%) which seem to be visually narrower than before.

It might be of interest that some monospaced fonts choose to align 3 fullwidth characters with 5 Latin characters (eg yuru7/moralerspace), giving a width of 300%/5 = 60% which is wider than current Cascadia Code.

yes. that what I mean

Ah yes. That makes sense. Indeed I would expect the Latin to look narrower than it did before, due to the change in width.

As I said, though, I recall there being a hard requirement around a 2:1 ratio in some coding environments so since the CJK forms are at 2048 ADW, the Latin will need to be at 1024.

could it have wider CJK fonts rather than thinning the latin font?

[aaronbell]

@heartacker I’m limited by whatever width of CJK characters I have available. I don’t (at least right now) want to try and widen (or narrow) existing forms mechanically.

[MiddleRed]

@heartacker I’m limited by whatever width of CJK characters I have available. I don’t (at least right now) want to try and widen (or narrow) existing forms mechanically.

Is it possible to keep latin characters in original width and instead of narrowing but make empty gaps between single CJK character to meet the requirement of 2:1

[aaronbell]

@MiddleRed Yes, that would be possible. Though I don't know if it is a better experience to increase the spacing between Chinese characters by 17% versus narrowing the Latin by 17%.

I think it might make more sense to enable two versions—one with 2:1 ratio and one without.

[mdtauk]

Is there a plan to integrate this into the original font, or is this intended only to be a variation for broader language support?

[aaronbell]

Again, not final, but my intention is that Cascadia Next will become the active project and the existing Cascadia Code will switch to KTLO but will not see further development. Everything in the existing project will be ported to the new one.

That way folks who like the way the font works now have access to it as we make breaking changes and move forward with the new version.

[mdtauk]

Thank you for that. Do you plan to share your plans for what you wish to change with Cascadia Next for other languages, and whatever new features you may plan to implement.

The Latin characters from the screenshot seem narrower, is that only for the Full Width Latin characters?

[aaronbell]

Yes, as I develop my plans further I plan to share the updates and beta versions not unlike this release along the way so you can get a sense of what’s happening.

As for the CJK, there is a hard requirement for standard Latin glyphs to be in a 1:2 ratio with CJK characters, so a narrower version of the Latin was developed. This will eventually become a width axis (varying from the standard 1200 advanced width down to 900). However, the narrower standard form you see here will only apply to the CJK which won’t have a width axis for the time being.

[NightFurySL2001]

Strongly voting against the use of Taiwan Educational reference orthography as the representative of Traditional Chinese (TC) in Cascadia Next. If there is no plan to support other TC regional orthographies (eg Hong Kong, Macau, Malaysia, Singapore), it would be better if Cascadia Next TC choose an orthography that is region-agnostic like jiu zixing or similar approach to IBM Plex TC (see issue IBM/plex#346 for community feedback).
Since it seems that the CJK part is using Source Han Sans, a few viable alternates that has variable weight are Shanggu Sans and ChiuKong Gothic.

[aaronbell]

@i-font Thanks for the feedback! It is useful to get differing perspectives on the approach to take. Taking the reference here of the 4 categories of TC fonts (with 1 being fully traditional, and 4 being fully modern), that the CL version falls more into category 2, and MN falls more into category 3. Is that an accurate assessment?

The challenge in this case, that I'd be interested to get your opinion on, is what would be the best category to use in the specific environment that Cascadia is targeting—namely, coding environments where the font is used at smaller sizes on low-resolution screens (even as far down as 72 dpi). Cascadia's Latin, for example, is not necessarily a design that is optimized for beauty and long-form reading in books or other publications, but has special modifications to make it more suitable for a coding environment. The lowercase /f, in particular, could probably be seen as heretical as the crossbar does not sit on the x-height as it Should (but doing so allows for clearer rendering of the top hook).

Comparing the MN and CL versions of ChiunKong in the link you provided, my general sense is that the MN versions of the characters tend to have simpler forms which are more likely to render more cleanly on screen (particularly at lower resolutions) than the CL version. For example, the items I've circled below will likely render more clearly in the bottom example (MN) versus the top example (CL). Would you agree?

So all that leads me to Consider that the category 3 approach strikes the right balance of clarity (given the environment) which is something that I believe coders prioritize, and bringing more of the traditional approach than the standard Source Han Sans. What do you think?

Of course, this isn't to say that I couldn't provide both options—perhaps something in the config where one can select between the two different variants—but one of the two has to be the default.

[chlbc]

To this reference, the CL version of ChiuKong Gothic (秋空黑體) is the first category and the MN version is the second category. The open source fonts of the third category includes Chiron Hei HK (昭源黑體), etc.

In addition, I made a mistake. “值” (U+503C) and “値” (U+5024) problem occur in some first category fonts such as Shanggu Sans (尙古黑體), but this problem does not occur in the CL version of ChiuKong Gothic and Shanggu Sans TC. For this part didn’t be verified, I’m sorry.
(In the case of some first category fonts, such as Shanggu Sans, if the user wants to search for the character “値” (U+5024) in the code, he may discover that some strings containing the character “値” cannot be find. Because these strings actually contain character “值” (U+503C), and there are many such situations in the CJK environment.)

Test Characters: 直 值 値 青 靑 請 遵

I understand that each Traditional Chinese user has his or her own preference for glyphs, and there are advocaties of both classic and modern styles. Perhaps @aaronbell can refer to the font sample of some well-known type foundries, such as DFHei (by DynaFont, 華康), AR Hei (by Arphic, 文鼎), UD Reimin Traditional Chinese (by Morisawa, モリサワ), and IBM Plex Sans TC (by IBM). I think the MN version (second category) is a common denominator between the modern standard and the classic standard.

For the above reasons, I recommend Cascadia Next using the MN version to be the default.

[aaronbell]

@chlbc thanks for the clarification!

[i-font]

先回應一下，@aaronbell 以爲像MN版本新式篡改後的字形在小字下比較清楚，其實不見得。比如閣下沒有圈出來的「請」字或所有从「靑」的字，都是CL版本或者傳統字形比較清楚。至於閣下圈出來的字，也不見得新式篡改後的字形就比較好，比如「滇」字或所有从「眞」的字，閣下以爲篡改成「十」頭比較易看，但事實上「十」頭的筆畫簡化，反而看起來不夠突顯，相反「匕」頭在視覺上，第一眼就看到「匕」形，不會與其他漢字的造型相混，這種足夠顯著的差異，反而令它在小字上更易辨認出來，可讀性更高。漢字的可讀性，不是簡單地覺得「筆畫較簡單」就較清晰，而是要比較跟其他字形的分別度。漢字的美感，也是歷經上千年的彫版印刷至今累積而來，這是傳統字形才具備的，像MN版本那種新式篡改後的字形是失去了的。

進一步來說，本討論串的樓主 ＠NightFurySL2001 其實就已經指出 IBM/plex#346 上大家的意見，在這原討論中，大家都是同意應當用傳統字形，或者稱爲傳承字形、舊字形（即是CL版本那種字形）。在原討論串中，大家一直擧出許多實例，有圖例，有實際書籍的例子，這是大家長年的閱讀習慣，當中所呈現的字形，都很明顯是傳統字形。討論中大家還指出了對一些新式篡改後的字形（即MN版本那種字形）的不滿。這些情況，本討論串的樓主一開始就指出來。可是 @chlbc 就已經把意見，扭曲爲主張大家所不滿的這種新式篡改後的字形。對此本人深感遺憾。而一些字形廠商，它們旗下的字型根本沒有好好統一字形部件，一直都讓用者不滿，根本不足爲例。

平衡地說一句，要是兩種字形也支援，我是支持的。但討論串的本來訴求，就是深切希望可以讓以像CL版本的傳統字形作爲預設的字型。

Translation provided by ChatGPT：

Let me respond briefly. @aaronbell believes that the newly juggled glyphs in the MN version are clearer at smaller sizes, but that’s not necessarily the case. For example, the character "請" or any characters derived from "靑" are clearer in the CL version or the traditional glyphs, which you did not highlight. As for the characters you did highlight, the newly juggled glyphs are not necessarily better either. For instance, in the character "滇" or any characters derived from "眞", you believe that changing the top part to "十" makes it easier to read, but in fact, the simplification of the "十" head makes it less distinctive. In contrast, the "匕" head is visually more noticeable at first glance, making the "匕" shape stand out, without getting confused with the structure of other Chinese characters. This clear distinction actually makes it easier to recognize at smaller sizes and improves legibility. The readability of Chinese characters is not simply about thinking that "simpler strokes" are clearer, but rather about comparing the distinguishability between different glyphs. The aesthetic of Chinese characters is also something that has been accumulated through thousands of years of woodblock printing, and this is unique to traditional glyphs, which is lost in the newly juggled glyphs like those in the MN version.

Furthermore, the original poster of this thread, @NightFurySL2001, has already pointed out the opinions from IBM/plex#346. In that original discussion, everyone agreed that traditional glyphs, or what can be called legacy glyphs or jiu zixing (i.e., those in the CL version), should be used. Throughout the original discussion thread, many examples were raised, with illustrations and real book examples, reflecting years of reading habits, and the presented glyphs were clearly traditional ones. The discussion also highlighted dissatisfaction with some of the newly juggled glyphs (i.e., those in the MN version). These issues were pointed out by the original poster of this thread right from the beginning. However, @chlbc distorted these opinions to advocate for the newly juggled glyphs, which many people are dissatisfied with. I deeply regret this. Some typeface vendors haven't even properly standardized the components of their fonts, which has consistently dissatisfied users, so they are not a valid reference.

To be fair, if both types of glyphs are supported, I am in favor of it. However, the original request in the discussion thread is a strong desire to have a font that uses traditional glyphs like those in the CL version as the default.

[shishamao]

I don't think the MN version is a good choice. From the usage of modern traditional fonts, except for the regional fonts of the Educational reference orthography, the more common ones are traditional printing fonts, which are more traditional than MN. The MN version is more like an alternative font that is extremely rare and mixed with JP glyphs. This is not a good choice. ShangguSansTC and ChiuKongGothicCL are more suitable.

[NightFurySL2001]

It seems that SC/TC is missing fullwidth Latin glyphs, only fullwidth numerals n some symbols are present (between U+FF01..FF7F). U+FF0A seem to be a shapeshifter btw.

Also U+FE10 should be a comma on top right, not a quotation mark.

[smynudop]

JP is the same. I would like to see glyphs added to the full-width alphabet, as it is (unfortunately) frequently used for Japanese text. Additionally, the full-width asterisks seem quite different in form compared to the half-width asterisks.

Furthermore, it appears that JP is unable to display some Kanji characters. The characters in the image are part of the Joyo kanji set. Bold characters are not displayed in Cascadia Next JP and are falling back to other fonts.

Below is a list of characters that are not displayed in the image. Many of these characters seem to be used as radicals, but I'm not sure why they are not displayed.

一雨音火貝玉金月犬見口山子糸耳車手十女小人水生青夕石赤足大竹虫田土二日入白八文木目立力羽角弓牛魚言戸工行高黄谷止矢自首色食心西走長鳥刀肉馬麦父風米母方毛門用里血皿歯身豆皮鼻面羊衣欠士氏臣飛民老支示舌比非革干穴己骨至寸

I really like this font and am looking forward to the official release!

[lxgw]

Cascadia Next SC cannot be recognized as having multiple weights on Windows while TC and JP can.

[aaronbell]

Hi, I've updated the build system to fix the STAT table, and it looks like it is working properly in Windows now Archive.zip

[PeterXn]

@aaronbell cannot download.

[xchrix]

Trouble with font preview

Font 'Cascadia Next' show a wrong preview in Matlab R2024, and the font name has a font weight 'ExtraLight':

When I use 'Cascadia Code', I can see a normal preview of the font

Then I get a wrong font weight:

[aaronbell]

Out of interest, if you enter "Cascadia Next SC" without the "ExtraLight" does that work? One of the challenges with variable fonts is that they often have different font names built in (in font parlance, name table ID 1 vs ID 16), and what the application requires to display the font depends on how they were coded.

[xchrix]

I test the 'Cascadia Next SC' in VSCode, it works as expected.

But if I enter 'Cascadia Next' with no 'SC', it doesn't work.

[aaronbell]

Yes. You need the “SC” to get access to the simplified Chinese version.

[joesdu]

"Hope to make Chinese characters less square and more rounded, achieving an effect similar to this."
fonts file: https://1drv.ms/u/s!AuDqlDFLiGtSsLYCH3ITLQOzHmnQqw?e=svfxXS OR https://1drv.ms/f/s!AuDqlDFLiGtSsLYJ0Xs38yCOusYfxg?e=oUwsDJ

[NightFurySL2001]

This is a sans serif coding font.

[aaronbell]

Thanks for the suggestion! As @NightFurySL2001 says, though, I don’t think it would be the right design choice for this project.

[mdtauk]

As far as I understand, the Latin letter shapes are not changing radically, so the other language glyphs will be designed in sympathy with those letter styles. so the characters sit comfortably together.

[lxgw]

As a sans-serif font, Cascadia can hardly match those rounded fonts well, especially fonts with large rounded corners such as TsukuARdGothic. Besides, except derivative fonts, there is currently only one ready-made open-source font that looks like TsukuARdGothic, Zen Maru Gothic, yet this font supports Japanese only, and isn't variable font.

Thus, Cascadia Next has chosen Source Han Sans, a ready-made open-source variable sans-serif pan-CJK font as the CJK part of the font.

[yvvt0379]

"Hope to make Chinese characters less square and more rounded, achieving an effect similar to this."
fonts file: https://1drv.ms/u/s!AuDqlDFLiGtSsLYCH3ITLQOzHmnQqw?e=svfxXS OR https://1drv.ms/f/s!AuDqlDFLiGtSsLYJ0Xs38yCOusYfxg?e=oUwsDJ

Please do not. Absolutely. It's not widely accepted and differs too much from latin letters

[TomoeMami]

Windows Emacs (31) render problem:

[aaronbell]

Weird. I wonder how that happened. Must have been when I messing about with the vertical metrics.

[JasonZ-99]

I'm having the same problem with the "Windows Notepad" and "Kate", but it works fine with "Windows Terminal".

[hanubeki]

I think there are some mistakes in metrics (values below are viewed by FontForge)

I think OS/2 Descent should not be smaller than General Descent

[garmede]

Wasn't Korean part of the plan?

[aaronbell]

There wasn’t funding available to produce a custom Korean previously. Hopefully soon!

[notpdpton]

Cascadia Next SC cannot be recognized as having multiple weights on JetBrains IDE, only ExtraLight.
Version: a0f40c6(2024-08-29) on Windows

And for Cascadia Code, it's only one font in font list, but several weight in weight list.

[aaronbell]

Can you confirm that you're using version 4.301?

[notpdpton]

Can you confirm that you're using version 4.301?

Yes, I even redownloaded and reinstalled.

[heoq]

Same here on windows but not macos
This is windows:

This is macos:

[tzengshinfu]

Cascadia Next TC also only has ExtraLight on JetBrains IDE in WSL2.

[subframe7536]

JetBrains' IDE will only show the style in default master currently

[JackerGamer]

Thank you very much for adding Chinese support in Cascadia Next. However, I noticed that the 1:2 width ratio between Latin and Chinese characters is achieved by reducing the width of Latin characters.

I suggest keeping the original aspect ratio of Latin characters. Your previous suggestion of increasing the spacing between Chinese characters by 17% may be a solution. This seems to be the case in Windows Terminal.

Of course, to meet different user preferences, you can consider providing multiple versions for selection.

[JackerGamer]

I noticed some users gave a thumbs down to my previous feedback. To clarify, my suggestion is to preserve the original aspect ratio of Latin characters in Cascadia Next. Reducing their width to achieve a 1:2 ratio with Chinese characters compromises the original design of Cascadia Code, which could negatively affect readability and consistency for those familiar with the older font. I'm not advocating increasing Chinese character spacing as the only solution—there may be other ways to balance the widths without altering the Latin character proportions.

[longlongvip]

支持什么中文编码，GB2312？GBK？GB18030？

[lxgw]

Cascadia Next SC 包含 GB/T 2312 所有汉字，以及 GB/T 12345 收录的部分繁体字，总共 9169 字。

Cascadia Next SC contains all the Chinese characters in GB/T 2312 and some of the traditional Chinese characters in GB/T 12345, totaling 9169 characters.

[windxisteal]

It seems that I found some minor bug in certain situation.

There is a screenshot from VSCode Terminal, And we can see that "gjpqy" these letters are cut off when we reach the last line of the terminal.

Cascadia will not have such problem

It happens when no space is reserved at the bottom of the terminalwindow. Therefore, terminals like Windows Terminal, which reserve space, won't encounter this issue.

[YexuanXiao]

As a Chinese user, I am very pleased that Cascadia Code has brought this topic to light (it is often misunderstood and overlooked). However, to be honest, I'm not thrilled with the current approach of embedding CJK glyphs into Cascadia Code for the following reasons:

1. The embedded glyphs in Cascadia Code are fixed, which some people may not like.
2. Chinese characters have different variants in term of shape, and different regions have different conventions.
3. Windows 11 Canary already includes Noto Sans, which is essentially Source Han Sans.

In contrast, I would like to propose my solution:

Since all CJK characters have the same width, they are all monospace. Both VSCode and Windows Terminal currently have varying degrees of font fallback capabilities. So simply letting Cascadia Code cover non-CJK glyphs and using fonts with actual CJK glyphs as fallback should suffice.

Additionally, I believe there is one thing worth considering: Due to historical reasons, the ’ character in CJK fonts has the same width as character 水, but in fonts designed for English, it has the same width as .. This is also the difference between "Microsoft Yahei (微软雅黑)" and "Microsoft Yahei UI": the former is for Microsoft Word, while the latter is for the system UI.

Lastly, I strongly oppose making Latin letters half the width of CJK characters, as this would result in very poor display quality.

[aaronbell]

Thank you for your suggestions! While I fully appreciate the ease of using fallback behavior to fill in the Hanzi characters, it isn't an ideal implementation either.

1. Fallback glyphs aren't weight / size adjusted to work well with Cascadia, so you will always see a difference in styling between Latin and Chinese, which would be undesireable. Additionally, Cascadia is used outside of Windows environments, so I want to be able to enable CJK applications for those users as well.

2. There are indeed different conventions. However, one challenge with coding environments is that they don't have good support for OpenType features, so even if we relied on fallback, one may not be getting the kind of character designs desirable anyway. Better, IMO, is to provide different variants of Chinese (that make sense) that will work for different users. In the case of Traditional, there's some complexity, but I think a generally acceptable approach can be achieved.

Due to historical reasons, the ’ character in CJK fonts has the same width as character 水, but in fonts designed for English, it has the same width as .. This is also the difference between "Microsoft Yahei (微软雅黑)" and "Microsoft Yahei UI": the former is for Microsoft Word, while the latter is for the system UI.

Thanks, I'll look into this.

Lastly, I strongly oppose making Latin letters half the width of CJK characters, as this would result in very poor display quality.

I can see how one might prefer wider Latin forms (though I've started liking the narrower ones myself). As I've written previously, there are historical environments where half-width Latins are required, but modern environments may not have this restriction. I think it worth offering both.

---

Finally, I think it worth noting that I'm not planning on embedding CJK into the standard version of the font. If you want Cascadia without the CJK glyphs, that will be available. I'm assuming there are many developers who don't need those characters :). So it would be opt in, rather than opt out.