Cascadia Code/Mono text height doesn't match original

[longnguyen2004]

🗹 Requirements

• I have searched the issues for my issue and found nothing related and/or helpful
• I have searched the FAQ for help
• I have searched the Wiki for help

🎯 Subject of the issue

Experienced behavior:
The patched Cascadia Code font doesn't have matching text height to the original, which makes it look unusually large

Expected behavior:
The 2 fonts to have identical text height

Example symbols: Letters and numbers

🔧 Your Setup

• Which font are you using
  • Caskaydia Cove Nerd Font Complete Regular.otf
  • Downloaded from GitHub Releases
• Which terminal emulator are you using (e.g. iterm2, urxvt, gnome, konsole)?
  Windows Terminal
• Are you using OS X, Linux or Windows? And which specific version or distribution?
  Windows 11 22H2

★ Screenshots (Optional)

Original

Patched

[Finii]

Here a visualization of the changes:

Could you please share the font details one can see with the font settings dialog when you click on that concrete font?

I guess you compare the static nerd font version with the dynamic variable default-for-Windows-Terminal version?
Those two differ already when you download them as original, iirc.

Edit: It's called VF, variable font

[longnguyen2004]

Which font settings dialog are you talking about? The one in Windows' Settings app?

[Finii]

I have no clue how it is called 😬

Windows-Key, type fonts, hit enter (this is how I access it). Where you can see all installed fonts. Yes, I guess Settings "app".
Click on the font, a new window opens where you see a sample, the version number, installed variants, pathname, ...

(Can not do a screenshot right now, sorry, would need to start some Windows box).

[Finii]

Note, I have the non-VF installed on that machine. Windows Terminal bundles with the VF fonts and it is a nuisance to remove them and install the static Cascadias instead. This is almost Apple-esque.

[longnguyen2004]

Original:

(Using Cascadia Mono here since I currently have the VF version of Code installed)

Patched:

And just to make sure it's not Windows Terminal messing me up, here's a comparison in VS Code

[Finii]

🤔 That's ttf vs otf, hmm

Can you try Delugia instead, that is ttf based.

[longnguyen2004]

Sure, I'll also test otf vs otf tomorrow

[Finii]

🤔 Even the equal signs look different 🙄

[longnguyen2004]

Cascadia Mono ttf vs Delugia ttf

Ignore the ligatures. Equal signs are correct, but text height is still not

Cascadia Mono otf vs CaskaydiaCove otf

Once again, ignore the ligatures. These 2 perfectly match, but they don't match the ttf version.

I've dug through the issues list for both CC and NF and found microsoft/cascadia-code#371 #519. Apparently, it's related to hinting somehow. This might explain the difference between ttf and otf, but it doesn't explain why Delugia also looks wrong.

[Finii]

Thanks for the investigation.
Will try to find something out.

Which reminds me that VS2022 renders the patched fonts (sometimes) rather rough, or the other way round, the unpatched Cascadia Code unusual smooth. I guess it was

• Caskaydia Cove not displaying on visual studio code, but displayed correctly in the integrated terminal. #785

[longnguyen2004]

Alright, crazy idea:
I used the fonttools package to generate the 6 static fonts from the variable font, and run it through NF patcher, and it worked

Here's the resulting font files
Caskaydia Cove PL Static Nerd Font.zip

So I guess it just comes down to the difference between the VF and static version of the original font?

[Finii]

But we use the static ones. I guess you compare against the VF Cascadia, although you think you don't ;-)

As you use windows terminal, which always installs the VF, I wonder how you got rid of them ;-) (see comments above).

You did not show an equivalent screenshot to the first one of my #998 (comment) (search fonts for casc).

Usually you have the VF from terminal and additionally the static ones, and of course always the VF are used. Even if you deinstall windows terminal you need to reboot, although because the VF is still in the font cache :-(

[longnguyen2004]

Alright, so I removed every instance of Cascadia Code/Mono I installed, and then installed Cascadia Code PL static, to prevent conflicts with Windows Terminal's bundled version. This should be what you expected.

So, here's some more (hopefully final) comparisons

Cascadia Code PL ttf vs Delugia ttf

Cascadia Code PL otf vs Caskaydia Cove otf

So the otf is identical, but the ttf isn't, and they're not identical to eachother. I'm starting to think this is an upstream problem, and it might be related to the use of autohinting, instead of the manual hinting in the VF version. In any case, if you want to investigate further, we can leave this open.

[Finii]

Thanks for the work. I will try to pick this up and get to the bottom of it.
I remember some comment by Aaron Bell on the static fonts, *ponder* what was it? too long ago.

[aderusha]

Experiencing the same thing here on Win 11, this is particularly problematic in i and j characters as the dot gets squashed into the letter body, making them hard to distinguish.

[aderusha]

Here's an example showing what happens when, say, a lowercase i lands next to the numeral 1:

Caskaydia Cove Nerd Font from v2.3.3:

Patched font CaskaydiaCovePLStatic Nerd Font from longnguyen2004:

[Finii]

@aderusha Thanks for reporting these interesting finding.

Patched font CaskaydiaCovePLStatic Nerd Font from longnguyen2004

Can you point me to the exact repo? I do not find their CaskaydiaCovePLStatic Nerd Font.

[aderusha]

Can you point me to the exact repo? I do not find their CaskaydiaCovePLStatic Nerd Font.

I'm testing the patched version provided a few posts above in the thread here. File is labelled Caskaydia Cove PL Static Nerd Font.zip

[Finii]

Ah, those are ttf and not otf

If I remember correctly we already found out that the original (unpatched) Cascadia Code static-otf files already have this issue, and we can not really do anything about that, other than switching to the ttf version.

I will do some more checks and conversion tests. I guess we will have to raise an issue upstream if we want to have that fixed.

I'm not sure WHY Nerd Font uses the otf version of Cascadia Code. There might be reasons.

Ah, but then above longnguyen2004 shows a difference between ttf based Delugia and ttf Cascadia Code.

What is wrong with that font? No other font has these problems, and I do not even see them on Linux (or do I?)
I need to consolidate the multiple threads around this problem. I remeber doing more experiments but not here 🤔

[Finii]

Other main thread: adam7/delugia-code#78

[Finii]

This all seems to be not conclusive.

If we just concentrate on TrueType outlines (i.e. .ttf files), my result was

• Cascadia Code unpatched VF versus static show the difference
• Cascadia Code static versus Delugia does not show the difference

@longnguyen2004 said the difference between VF and static vanishes if the statics are self-produced and not taken from the Cascadia Code release.

Here @#998 (comment) sees the difference but does not specify if static or VF.
But later #998 (comment) it is static. Difference visible for ttf but not for otf?

Strangeness.

[ubergeek77]

@longnguyen2004 The version of the font you posted is identical to the original Cascadia Code on my system, thank you very much for figuring that out. This is exactly what I was looking for.

Can you share the commands you used to convert these the way you did? I'd like to automate the process of keeping Cascadia Code up to date with the latest version of Nerd Fonts, but I'm not sure how to get static fonts without making 48 of them 😅

[longnguyen2004]

@Finii Here's a TL;DR
Using the VF font as the ground truth:

• Static (TTF): Wrong
• Static (OTF): Even more wrong
• Delugia (patched static TTF): Wrong (same as original)
• Caskaydia Cove (patched static OTF): Wrong (same as original)

So we can't use the upstream static fonts to make the patched fonts, because they will look wrong. Instead, we need to take the VF font, and generate static versions from it (using fonttools and this table as reference), and then patch the resulting static fonts.

@ubergeek77 I'll probably make a script to automate the process when I have some free time.

[Finii]

@longnguyen2004 You did notice

• Improve ttfautohint hinting microsoft/cascadia-code#371

(towards the bottom)?

I'm not sure what you want to do with the fonttools, but you can not reuse the VF hinting in the static fonts, so you end up using an unhinted font or employ some autohinter. I guess with fonttools you would use ttfautohint, which ... will result in the same static fonts that Cascadia Cove already has, because would you describe is exactly how they are generated.

So this boils down to using a different autohinter, in particular VTT or TTH, both which can not be scripted and one that is not even free. I do not have any solution for that except doing it by hand. That is still possible and wound just take 5 minutes on my machine, but still is unsatisfactory because we introduce a differently hinted font.

Maybe we should 'just' add VF patching, then we can keep the original hints and have the symbols etc. In another thread we discussed the way to patch VF fonts, which would probably drop using fontforge. Which is a major redesign.

I am not sure here. I believe it is not possible to really automate the process (but you claim otherwise with 'script to automate'). If it is possible I would just put that process in the release workflows and we are good here. Please let me know especially how you want to hint the static fonts after creation. That is the crucial question.

If that is not possible we could manually hint the static source fonts (manually means automatically but triggering the autohinter manually, not really doing manual hints) after each Cascadia Code release and put that fonts as sourcefonts here. But will be there someone who does it for the next Cascadia release? What happenes when Aaron fixes the original static fonts himself? Etc.

For me this is all not too clear.

[longnguyen2004]

I'm using fonttools' varLib.mutator to generate static fonts, and I've seen someone said that VF hints still work after instancing. I'm no font expert though, I'm just exploring different approaches, and have no idea how to verify if hinting still works after generating the static fonts. You can check the resulting font yourself in the archive I uploaded.

Btw, I noticed that fonttools also has a font merger. Can we use that somehow? Doesn't work with VF

[Finii]

That is easy to check and I really want to, but I'm a hair away from finally releasing 3.0.0. So that will have to wait (please ping me if I forget 😬 )

But, unrelated, do you have an idea for a name replacement for good old Bitstream Vera (Issue 1173) :-D

[longnguyen2004]

How about Bytestream Vira? :)

[Finii]

Thanks!!

This looks good. The hints are preserved and subpixel rendering in fontforge looks identical to what I got in the other experiments that looked good.

Question still is if that (the overlapping outlines) will be an issue on Mac, as detailed in the Issue you linked above (fonttools/fonttools#1281, https://github.com/twardoch/test-fonts/tree/master/varia/160413-EvenOddTT)

That issue is closed, though. Did not dig too deep into that right now.
If this seems all good we should ask Aaron why he choose to instantiate the statics with simplified outlines (just because the is the default or some specific reason).

[longnguyen2004]

Ping me on the relevant issue when you get around to it.
@ubergeek77 The relevant script to generate the static fonts are above. Should be pretty simple to substitute them into the Nerd Fonts repo and regenerate that way.

[Finii]

Aaron seems to use fontmake.Instantiator to create the statics...:

Yes, if the static fonts with overlapping outlines can be used that makes everything here super-simple. 👍

[Finii]

And your instance has Panose right, something that is broken in the original release-static.
:-D

[longnguyen2004]

Note: Please do not use the fonts above for the release, as the naming table does not follow the naming convention. I'll edit my script to copy the naming table from the original font to the generated one.

[longnguyen2004]

The relevant code that removes overlaps in static fonts: https://github.com/microsoft/cascadia-code/blob/017bde551af6af419cc5554c37bbdffa4f9388ed/build.py#L285-L296

[Finii]

Note: Please do not use the fonts above for the release, as the naming table does not follow

We rename the fonts completely anyhow (build all name parts from scratch and fill them into all the appropriate tables). If nothing else works we use the filename to deduce the name parts 😬 (iirc)

Whatever. With your latest finding (overlaps removed explicitly) the question is if we should go the keep-the-overlap route, or - at least for the upcoming release - just use manually offline hinted fonts.

And switch to ttf for that. Do you know any reason why we should stay with the otf (or why they might have been choosen to begin with)?

[longnguyen2004]

Let's go with the keep-overlap. Manual hinting means extra work, and it'll not match 100% with upstream. Also, ttf or otf is fine, we can just tell the user to uninstall the previous version (and don't ask me why otf is used here, I'm not the maintainer of this 😁)

[longnguyen2004]

Generated statics, with name table copied from the original font
CascadiaCode Static (fonttools).zip

[Finii]

Thank you for preparing the font files 👍

But I guess Aaron has a point and we should stick with non-overlapping outlines.

We had overlapping outlines in some symbols and I manually fixed/removed them because they raised rendering issues for some people.

[Finii]

Starting release 3.0.0 (offline) 🎉

[longnguyen2004]

Funnily enough, I was experimenting around with ttfautohint again, and managed to produce a font that very closely matches the original VF:

12pt:

8pt:

The trick? --x-height-snapping-exceptions=-. That's it.
Going to submit a PR upstream, I finally cracked the code.

(Also, don't trust Windows Terminal's preview, that's wrong as hell)

[Finii]

I tried that exception, I believe I mentioned it in the Cascadia Code Issue.

The problem with that is that the top of the lower case letters gets blurry if you switch it on. Because they are not hinted at all anymore. Maybe that is only visible with some heights.

[Finii]

Hmm, seems I did not mention it...

This is what BladeMF wrote:

Have a look at the fonts with VTT, it is easy to just see the rendering, and easy to install under Windows.
You just use it to have a look, that is not complicated.
Download link and screenshot of that are in #1179

If you have fontforge installed under windows, open one glyph (for example i) and go to View -> Grid Fit -> Show Grid Fit... and select 96 dpi at 15 px, monochrome (anti-alias is broken, at least on my machines).

[Finii]

The height is roughly ok but all other details suffer 😬

[longnguyen2004]

Is it supposed to look like that? 😆

Anyway, I'll continue experimenting with different x height snapping values, to see if we can arrive to the closest appearance possible.

[Finii]

Is it supposed to look like that? laughing

select 96 dpi at 15 px, monochrome (anti-alias is broken, at least on my machines)

This is anti-aliasing view, it's broken. switch to monochrome.

This toggles it on/off:

[Finii]

But the green outline is shown correct, and - as you already noticed - has the right height (moves down instead of up).

Here you need to check for example the 8 and where the middle-horizontal is. I remember I used Windows Terminal as test text.

But maybe the font is indeed good - waiting with the release until we have a conclusion here.

[Finii]

Hint: With the i try different sizes (alt-= and alt--). The top of the stem (where my arrow is) should always be at a pixel border and never in between (that would render it greyish and thus unsharp).

Other interesting glyphs as I said the 8 (where is the middle horizontal), the capital W (where is the point where the two v meet in the middle), ...

[Finii]

Here the v3.0.0 RC in Fontlab, Cascadia Code for comparison has (part of) a purple dot (animated gifs):

At 14ppm:

At 16ppm:

BTW, du you really use an 8pt size? Your display must be really bad DPI wise? 😬 I would have thought nowadays everyone has at least 100 dpi.

[Finii]

Also did a quick run through TTH, the glitches are comparable to VTT, but the overall appearance is a bit too light (esp roundish vertical parts). Also the 8 looks really different.

Cascadia Code

Caskaydia Cove (v3.0.0 with VTT)

Caskaydia Cove after TTH

The lower bowl is bigger, slightly, but that is exaggerated by TTH's hints 😲
Black line: 'theoretical' outline; blue line: outline after hinting

[longnguyen2004]

Nope, I use 12pt like others, and the x-height hack actually looks fine, I just wanna see how it looks on smaller size. But I guess I'll ignore that, because there are some glyphs that I just can't match on smaller size (like W on 7pt). How about trying to match from 9pt and up, and ignore everything lower?

Btw with your font, a, e and 8 have a bigger hole (which is also what I observed on ttfautohint)

[Finii]

From the images above I would say we could/should remove all hints from the 8 maybe (manually).
One could put some effort into optimizing the hints. We could examine [a-zA-Z0-9] or so ;-)
But then, stop there?
And quickly we are in manual hinting.

I would say manual hinting is for after 3.0.0. The only question now is use my already pushed VTT fonts or your no-x-height-snapping ones? Can you put the Regular font somewhere, then I can quickly open it in Fontlab.

[longnguyen2004]

Let's get 3.0.0 out first, I'm still in the process of experimenting

[longnguyen2004]

ttfautohint, nsn stem width, x-height-increase-limit=14, x-height-snapping-exceptions=-
CascadiaCode-Regular-nsn-increase14-except-.zip
Probably the closest we could reach before resorting to manual hinting

Here's a comparison at 12pt

[github-actions]

This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference.