Cascadia Next SC, TC, and JP #762
Replies: 21 comments 76 replies
-
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. Look forward to supporting Ligatures in the future. Cascadia Next SC
Cascadia Code
|
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
I feel that the Cascadia Next font looks thinner. |
Beta Was this translation helpful? Give feedback.
-
I think it's to make the font weight more consistent with the Chinese characters. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
The font is very beautiful! but I cannot apply it like other fonts in keil uvision5.38 :( |
Beta Was this translation helpful? Give feedback.
-
|
Cool! Is there a brief somewhere for what "Next" is going to be about and how it will differ from "Code"? |
Beta Was this translation helpful? Give feedback.
-
|
I’ve written a number of thoughts down but haven’t announced anything final. To summarize briefly my ideas:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 🫠 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hm. Not sure why that would be the case. Are you able to use the font elsewhere? |
Beta Was this translation helpful? Give feedback.
-
Yes, the font appears in Acrobat and nearly all other applications, just not in Photoshop. Tested on both Windows and macOS. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
We've updated the fonts in the beta release with a corrected STAT table, if you'd like to try it out 😄 |
Beta Was this translation helpful? Give feedback.
-
|
If you could provide another variant of merging cjk, it would be useful. |
Beta Was this translation helpful? Give feedback.
-
|
yes, that would be great |
Beta Was this translation helpful? Give feedback.
-
|
What do you mean? |
Beta Was this translation helpful? Give feedback.
-
Maybe Cascadia Next, Latin + SC + TC + JP in one ttf/otf file? |
Beta Was this translation helpful? Give feedback.
-
|
Ahh I see. I’ll have to consider if that is viable given the character counts. |
Beta Was this translation helpful? Give feedback.
-
|
the next font is thinner than ever before, could you please make it A little wider |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
I stillllll believe that we should hold the latin and widen CJK , spacing OR something else and most important CJK :LATIN 2:1 should always be |
Beta Was this translation helpful? Give feedback.
-
I think everything is fine with the NEXT SC font right now, the spacing between Chinese characters don't need to be wider because that would be really ugly. You could try maple font, that might be what you want. |
Beta Was this translation helpful? Give feedback.
-
|
Is there a plan to integrate this into the original font, or is this intended only to be a variation for broader language support? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
In the ChiuKong Gothic (秋空󠄁黑體), I recommend using the CL version (舊式印刷體字形版本), not the MN version. This is because the so-called ‘modern pen shape’ is still changed the original glyphs to some extent. The CL version is really in line with the habits of most Traditional Chinese users and publications. Moreover, some character distinctions ( like “值” (U+503C) and “値” (U+5024) ) are in fact a serious violation of and damage to traditional printing and character usage practices. In fact, a large number of academics and members of the industry have already expressed their dissatisfaction. In addition, I also recommend using Genki Gothic 2 TC (源起黑體丹), not Genki Gothic 2 TW (源起黑體月). The graph style of this font is really suitable for Traditional Chinese users’ habits. |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. 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. |
Beta Was this translation helpful? Give feedback.
-
|
@chlbc thanks for the clarification! |
Beta Was this translation helpful? Give feedback.
-
|
先回應一下，@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
Cascadia Next SC cannot be recognized as having multiple weights on Windows while TC and JP can.
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@aaronbell cannot download. |
Beta Was this translation helpful? Give feedback.
-
Trouble with font previewFont '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: |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I test the 'Cascadia Next SC' in VSCode, it works as expected. |
Beta Was this translation helpful? Give feedback.
-
|
Yes. You need the “SC” to get access to the simplified Chinese version. |
Beta Was this translation helpful? Give feedback.
-
|
"Hope to make Chinese characters less square and more rounded, achieving an effect similar to this."
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the suggestion! As @NightFurySL2001 says, though, I don’t think it would be the right design choice for this project. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Please do not. Absolutely. It's not widely accepted and differs too much from latin letters |
Beta Was this translation helpful? Give feedback.
-
|
This font with rounded corners looks very informal. Personally, I think this style is ugly. |
Beta Was this translation helpful? Give feedback.
-
|
Windows Emacs (31) render problem:
|
Beta Was this translation helpful? Give feedback.
-
|
Weird. I wonder how that happened. Must have been when I messing about with the vertical metrics. |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the same problem with the "Windows Notepad" and "Kate", but it works fine with "Windows Terminal". 
|
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Wasn't Korean part of the plan? |
Beta Was this translation helpful? Give feedback.
-
|
There wasn’t funding available to produce a custom Korean previously. Hopefully soon! |
Beta Was this translation helpful? Give feedback.
-
|
Cascadia Next SC cannot be recognized as having multiple weights on JetBrains IDE, only ExtraLight.
And for Cascadia Code, it's only one font in font list, but several weight in weight list.
|
Beta Was this translation helpful? Give feedback.
-
|
Can you confirm that you're using version 4.301? |
Beta Was this translation helpful? Give feedback.
-
Yes, I even redownloaded and reinstalled. 
|
Beta Was this translation helpful? Give feedback.
-
|
Same here on windows but not macos |
Beta Was this translation helpful? Give feedback.
-
|
Cascadia Next TC also only has ExtraLight on JetBrains IDE in WSL2. |
Beta Was this translation helpful? Give feedback.
-
|
JetBrains' IDE will only show the style in default master currently |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
CJK characters look better if their forms are slightly extended horizontally, not only their spacing. c.f. Meiryo (Japanese non-coding font in Windows since Vista):
Other fonts (BIZ UD Gothic + JetBrains Mono): yuru7/udev-gothic#18 (1.05x) https://github.com/qrac/soroemono For markup languages (Markdown and HTML), the current is preferred because of the ratio of CJK characters in source code. |
Beta Was this translation helpful? Give feedback.
-
|
支持什么中文编码，GB2312？GBK？GB18030？ |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that I found some minor bug in certain situation. 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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
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 Lastly, I strongly oppose making Latin letters half the width of CJK characters, as this would result in very poor display quality. |
Beta Was this translation helpful? Give feedback.
-
|
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.
Thanks, I'll look into this.
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. |
Beta Was this translation helpful? Give feedback.
-
|
As a simplified Chinese user, this NEXT SC font is very beautiful. Especially when Chinese and English characters are displayed together. |
Beta Was this translation helpful? Give feedback.
-
|
I installed the font from github release page and set font in windows terminal and vscode to "cascadia code nf" both, but strangely Chinese font is not available in vscode. It works fine in windows terminal though. In windows terminal: In vscode: Does it have something to do with font size? |
Beta Was this translation helpful? Give feedback.
-
|
The version of the font that you're using does not presently have Chinese characters included. You need to download the "Cascadia Next" demo fonts from here: https://github.com/microsoft/cascadia-code/releases/tag/cascadia-next. So what you're presently getting is font fallback. |
Beta Was this translation helpful? Give feedback.
-
|
So the cascadia font shipped with windows terminal has CJK characters and Chinese contents fallback to use default mono font rather than "cascadia code nf" I set in the settings, am I understanding correctly? |
Beta Was this translation helpful? Give feedback.
-
|
They look harmonious so I thought they are from same font, that helps a lot. |
Beta Was this translation helpful? Give feedback.
-
|
Cascadia Next SC not marked "monospace", some font selector cannot see that font which only allow monospaced ones: |
Beta Was this translation helpful? Give feedback.
and others
-
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.
Beta Was this translation helpful? Give feedback.
All reactions