New Cascadia Code not good in Emacs

[angelog0]

Since you released the first version of Cascadia Code, I adopted it in Emacs.

With RC1 of WT, I configured both Emacs and WT to use Cascadia Code-12 and Emacs was configured to use 49 lines, say 46 for text and 3 for tool bar, scroll bar etc. Before this setting I had Cascadia Code-11 both in WT and in Emacs in which I could use 52 lines of text!

Now after the upgrade to RC2 of WT, with the same configuration, in Emacs I have only 40 lines: 37 for text and 3 for the other things. Now in Emacs the gap between two consecutive lines appears too big. See this screenshot:

Even if I set to use Cascadia Code-11 in Emacs, I can use only 38 lines of text, i.e. I gain only one line passing from 12 to 11 in Cascadia Code!

In WT the text appears more or less as in RC1. The above picture compares how the text is in WT and in Emacs. As you can see, in the settings.json', indefaults` field, I have set WT to use Cascadia Code 12 as in Emacs. Now in Emacs I have too few lines!

[DHowett-MSFT]

Transferred this to the Cascadia Code repository. @aaronbell - report of typo metrics breaking folks.

[aaronbell]

@DHowett-MSFT Is this with the new version I uploaded in April?

[aaronbell]

In a recent update to Cascadia Code, we modified the font metrics to enable more consistent rendering across different environments and operating systems. It is a bit complicated to explain, but basically there are three different metrics values, and I brought better alignment between them. This is why WT RC2 and RC1 render pretty much the same.

However, in situations where an app only paid attention to a specific set of metrics—the sTypo metrics—there will be a noticeable increase in line spacing. This is, unfortunately, unavoidable.

On the plus side, from searching online, it appears that line spacing is fairly easily modifiable in Emacs: https://www.emacswiki.org/emacs/LineSpacing (or check the wiki of your software of choice).

Closing as by design.

[DHowett-MSFT]

For what it's worth, I see this in Vim as well. It looks like these editors are using GDI, which reports, very approximately, the winAscent/winDescent. ☹️

The cursor is super tall, and it handles line spacing very poorly (subtracting it mostly from the bottom.)

Is there a cheap improvement we can make? I do know we're following the Google typographic guidelines, though, so, I dunno.

[aaronbell]

The only solution would be to set winAscent and descent back to what they were. But that could reintroduce clipping in GDI environments.

Unfortunately GDI is too old.

[angelog0]

On the plus side, from searching online, it appears that line spacing is fairly easily modifiable in Emacs: https://www.emacswiki.org/emacs/LineSpacing (or check the wiki of your software of choice).

The suggestion does not work because line-spacing is by default nil which means 0 gap Adding something in it would increase the gap.

Anyway even using a lower height for the font does not improve the situation. Previously with Cascadia Code-11 I had more than 50 lines of text. in the same vertical space (my Emacs covers all the vertical space of the screen excluding the app bar). WHY?

[hummeleBop]

Cascadia Code 2004.30 here.

On gvim, playing with linespace doesn't help that much. (I even tried negative values, it generates some weird artefacts).

[angelog0]

I flagged the issue to Emacs people: https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01950.html

maybe you could be interested to know what they think about this issue.

Someone in that thread flagged that master (which I use), really uses HarfBuzz to display characters and not GDI...

Meanwhile, it seems I'm not the only one who sees this issue and not only with Emacs.....

[angelog0]

Maybe this issue should be reopened...

[Taomyn]

@angelog0 thanks, yes it does appear to be the same issue as I am having in NotePad++ under Windows

[aaronbell]

Thanks for the info. I am not super familiar with Emacs.

So you wanted to know why line spacing has increased. On Windows, Emacs appears to use the winAscent and winDescent values to determine line heights, and if anything extends beyond those values, it is clipped.

As such, when the winAscent and winDescent values are kept smaller, the font is completely unusable for Vietnamese texts as the crucial diacritics on capital letters are completely gone:

Here's how it looks on MacOS, which doesn't clip the characters:

As such, I do not intend to modify the winAscent value. However, as I mentioned on #269, I will increase the winDescent value, which should help you with fitting more lines in the window—I think it should get you back up to about 45.

[angelog0]

Hi @aaronbell, it seems that your font works only in Windows Terminal. I hadn't yet view #270. Now I started Command prompt and it is unsable unless I change font. This mark the new version of Cascadia Code as buggy. I am afraid.

Now I am on the search of another font to be used with Emacs and friend.

[aaronbell]

@angelog0 Actually, the font is standards compliant, and works correctly in various cross-platform environments. The issue here is with Emacs' approach to text layout, specifically on Windows. Should Emacs (a) provide more modern functionality in terms of line height customization or (b) correctly use sTypo metrics instead of winAscent per the fsSelection flag, then you would not have any issues. Unfortunately, it does neither.

In any case, good luck with your search.

[angelog0]

@aaronbell, but it affects also Command Prompt! you cannot make it "standards compliant" and break all these apps...

[aaronbell]

We're going to have to agree to disagree here.

Per the font specifications, winAscent and winDescent are meant to be used to indicate the maximum and minimum height of the font for clipping purposes. They were never meant to be used for actual line heights, or text size.

The problem is that legacy applications such as Command Prompt, and PowerShell, decided that winAscent and winDescent are the only font metrics necessary to use for typesetting purposes. This places the type designer in a quandary. Do we set the winAscent and winDescent values correctly per the font, thus creating a large line gap? Or do we set them incorrectly for narrower line gaps, thus preventing certain glyphs and languages from displaying correctly (such as Vietnamese)? Had these applications instead used the sTypo metrics for setting text (and winAscent for clipping, as intended), this issue would not exist.

Furthermore, neither of these applications are displaying text normally—both are scaling it to a set pixel height per 'point size'. This is why in #270 the text has suddenly become smaller when the vertical metrics are increased even though the glyphs themselves are the exact same size as before. Again, had the sTypo values been used, this wouldn't be a problem.

In both of the examples above, Command Prompt and PowerShell are treating text in a non-standard way. If I build Cascadia Code to take into account their legacy approach to text layout, we will always be trapped by their limitations.

Finally, this modification of vertical metrics does not impact the functionality or either Command Prompt, nor PowerShell. It may make text display slightly less ideal compared to other fonts, but such a change in a legacy environment is acceptable to me in exchange for the improvement in global usability.

[angelog0]

@aaronbell, but then you have to warn Windows, Windows Terminal and some other, to NOT use Cascadia Code as default font for Command prompte and PowerShell... Have you seen how now Command Prompt and PS are now?

BTW, how can I revert to previous version of CC, say 1911.21?

I have found only 2 Cascadia[,Mono].ttf* on the system and they are located in [...]WindowsApps/Microsoft.WindowsTerminal_0.11.1333.0_x64__8wekyb3d8bbwe/ and have the same shasum of https://github.com/microsoft/cascadia-code/releases/download/v1911.21/Cascadia[,Mono].ttf

I tried to substitute them but it refused, even as admin; maybe they are in use..

[Taomyn]

@angelog0 can you try Powershell v7? https://github.com/PowerShell/PowerShell/releases and see if that looks the same? I hadn't switched to Cascadia for it so I cannot tell if it changed,

Not sure if you can count PS7 as legacy as I think it was rewritten, especial for portability to other OSes - I could be wrong.

[angelog0]

@Taomyn, it uses Consolas 16...

[Taomyn]

@angelog0 yes, but what about with Cascadia, that's what I was hinting at?

[mdtauk]

@aaronbell If the difference is just a value change for the Ascenders and Descenders, perhaps there could be a Cascadia Code Legacy version built by the build process, for those who wish to use the font, but are using legacy applications?

I know this is going to also include localisation bugs, because of the diacritics, but how much of that legacy software, supports internationalisation, and how do other fonts render their diacritics and other international language strings?

[aaronbell]

@angelog0 Well, if you look at the 'release' message, it states:

We've changed the typographic metrics a bit to align with best practices and move away from using legacy Windows GDI values (#261)

That's a warning :)

It sounds like you receive the font via Windows Terminal. Due to the fact that Cascadia Code and Cascadia Mono ship with Windows Terminal, I am not aware of a way to override them. In fact, I created a bug about that!

For your purposes, I suggest installing the PL variants from the previous release. They won't be overridden by Windows Terminal and have the same metrics you are used to.

@mdtauk Both PowerShell and Command Prompt do support international codepoints, so are viable for international use. I should note, though, that the PowerShell that ships with Windows defaults to legacy codepage encodings rather than Unicode, but it certainly can display the codepoints. My understanding is that PowerShell Core defaults to UTF-8.

As such, I don't think it makes sense to introduce localization bugs and other issues simply so that the text is slightly larger on screen. Folks who want the version of the font with the old metrics can use the 1911.21 release.

The real difficulty here is that most coding fonts do not support Vietnamese. Fira Code, for example, will have the exact same problem when they finally add Vietnamese support as the diacritics will be completely clipped without modification to the winAscent. Other Microsoft fonts, like Consolas, had Vietnamese added years later after the font had seen extensive use. So the metrics couldn't be changed, and the diacritics are clipped. Not ideal at all.

[angelog0]

@Taomyn, more or less as current Command Prompt:

That is with Cascadia Code 16

[mdtauk]

@mdtauk ...

As such, I don't think it makes sense to introduce localization bugs and other issues simply so that the text is slightly larger on screen. Folks who want the version of the font with the old metrics can use the 1911.21 release.

Ideally other software will fix their font metric calculations and rendering. Windows has historically been a bit of a laggard with it's font support, and it wasn't until Windows 8 and DirectWrite did they start to fix that.

GDI is still a problem, not so much adding in fixes, but because of legacy software support. Many fonts have made assumptions to work on Windows, and so there will be these kind of issues going forward.

It will take a concerted effort among font developers, to persuade app developers to bring their rendering up to standards.

[DHowett-MSFT]

@angelog0 so, we just shipped 2005.15 with improved vertical metrics. Here's our compromise:

2005.15, today's release, is in the middle. It's not as tight as 1911.20, but we've killed a bunch of that vertical space. I hope it's more palatable. :smile:

[VladimirMarkelov]

2005.15, today's release

I've tested it in Neovim-Qt, and it looks great ;)

[angelog0]

@DHowett-MSFT, as I wrote here I have Cascadia*ttf only in Windows Terminal folder, so should I wait for a new release of WT? or should I click Install after the ttf is opened? In this case, will Cascadia fonts be upgraded with the upgrade of WT (overridden by Windows Terminal)?

[DHowett-MSFT]

It's .. complicated.

If you go install this new version as a normal font, for all users (right-click on it in Explorer), it'll override the version from Terminal only for applications that are not Terminal. It won't override it for Terminal.

[angelog0]

@DHowett-MSFT, hmm.. Is the simplest thing to do just replace the two Cascadia*ttf I find in C:/Programs/WindowsApps/Microsoft.WindowsTerminal_0.11.1333.0_x64__8wekyb3d8bbwe?

The fact is it refuses that...

[DHowett-MSFT]

I mean, no, the simplest thing to do is very emphatically not to try to replace read-only files owned by the app catalog.

The simplest thing to do is to install it like a normal font or right-click it and choose "install for all users"

[angelog0]

@DHowett-MSFT

The simplest thing to do is to install it like a normal font or right-click it and choose "install for all users"

..but you wrote that WT would ignore this installation... If I understand, WT will continue to use 2004.30 while the other apps will use 2005.15. I would like to have just one set of this font.

[DHowett-MSFT]

WT doesn't use the metrics that were changed in 2005.15. It shouldn't matter which one WT picks up right now.

Due to the way font registration works, you can't have just one set. Sorry.

[angelog0]

@DHowett-MSFT,

WT doesn't use the metrics that were changed in 2005.15. It shouldn't matter which one WT picks up right now.

Due to the way font registration works, you can't have just one set. Sorry.

I will wait for the next WT release then...