Bold characters are wider than regular ones when using the Light or SemiLight variants

[CutterXYZ]

Cascadia family version

2111.01

Cascadia family variant(s)

Cascadia Code (the version with ligatures), Cascadia Mono (the version without ligatures)

Font file format(s)

Windows Terminal included version (TTF (variable)), .ttf (variable)

Platform

Windows 10

Other Software

Tested in Eclipse IDE (2023-12) and Notepad++ (v8.6).

What happened?

When using the Light or SemiLight variants, bold text appears wider than regular text, regardless of font size.

Here is a screenshot in Eclipse:

In MS Word, there is no difference in width but bold SemiLight text is rendered strangely:

[DHowett]

Interesting! It looks like Eclipse is unaware that there is a Bold weight for this font, and is artificially creating a bold typeface by stretching out the glyphs.

This is an Eclipse (or perhaps SWT? If they're still using SWT...) bug.

For reference: the Cascadia family has a consistent bounding box size and glyph width for all weights present in the variable font. An application that can correctly map the bold weight to the corresponding named variation will display it just fine.

I suspect that Eclipse's issue is that it can't figure out that "Cascadia Code Bold" is the bold version of "Cascadia Code Light", and is therefore producing a monstrosity we can call "Cascadia Code Light Bold".

[CutterXYZ]

This is not just Eclipse. As you can see, Word also does some strange tricks with it and Notepad++ has the same behavior as Eclipse.

More examples:

Thunderbird

WordPad

Notepad++

[aaronbell]

Unfortunately this is a software limitation and not something (at least as far as I’m aware) that can be solved in the font.

[DHowett]

In my response, Eclipse is a representative example. Font family member mapping problems are not unique to Eclipse :smile:

[CutterXYZ]

~Results seem better with the fixed .ttf versions.~ Should I install both versions ?

[DHowett]

Results seem better with the fixed .ttf versions. Should I install both versions ?

It might be better to uninstall the variable font, if you can. If not, eh, it should be OK.

---

One of the easier ways to tell whether family-style-axis mapping is working properly is to look at the $ character¹.

$ only has a vertical stroke in lighter weights. Therefore, if you see a vertical stroke in your bold font . . . the text editor or UI toolkit that the text editor is using has invented a bold face and ignored the one that comes with the font.

Working

Broken

¹ (Wow, WordPad made it so difficult to generate a Working image that I gave up, Notepad++ wouldn't even load the font (???), and I am not installing Eclipse.)

[aaronbell]

It is really quite sad, so many years after the introduction of variable fonts, that app support is still so abysmal.

[CutterXYZ]

One of the easier ways to tell whether family-style-axis mapping is working properly is to look at the $ character¹.

Eclipse is indeed showing the Light version of the character and apparently applying some "bold" format to it.

[kenmcd]

Of course it does not work... There is no style-linking to a heavier weight (as the RIBBI "Bold) in the Light or SemiLight statics, or in the variable fonts. The Bold weight font is style-linked to the Regular weight font as the "Bold" in that RIBBI style group. The Light and SemiLight have no actual "Bold" variant linked in their style groups, so the apps are faking it.

We could create another RIBBI style group using the Light (or SemiLight) and the SemiBold (as the "Bold" of the style group) and that should work correctly. I can post them here if you want to test.

You could also test this with the old Ubuntu fonts (normal.v0.83, not mono) where the Light has the Medium linked as the "Bold". There are two RIBBI style groups in those fonts.

[CutterXYZ]

How should I test the Ubuntu font ? It is not monospaced, therefore I don't know if it being wider is normal.

However, I would gladly test the modified Cascadia font.

[kenmcd]

However, I would gladly test the modified Cascadia font.

These are the SemiBold static fonts style-linked to the Light fonts. In Word, or LibreOffice, or InDesign, or any app that can use the style-linking - when using the Light fonts the Bold and Italic buttons now link to the SemiBold fonts. They are now their own RIBBI style group.

Your application must be able to understand multiple RIBBI style groups correctly. The above mentioned apps do. It is not that uncommon. Old Ubuntu has two RIBBI style groups. Avenir has two RIBBI style groups. Janson has four RIBBI style groups. Myriad Pro has two RIBBI style groups. And one is just like this - Light linked to the SemiBold.

You cannot have the variable fonts installed at the same time. The style names may conflict (and probably will). Un-install the current SemiBold & SemiBold Italic. And install these. CascadiaCode-SemiBold-style-linked-to-Light.zip These are now style-linked to the Light in an RIBBI style group.

Light is your "Regular" and SemiBold is your "Bold". If your application is using the style-linking to make the "Bold" this should work.

[CutterXYZ]

With the static version of the font installed, Word renders the SemiLight bold and regular variants with the same width. This is both with the default static fonts, and the with modified fonts you provided (so, no change).

However Notepad++ renders both versions (default and yours) with a made-up bold variant.

[CutterXYZ]

Unfortunately this is a software limitation and not something (at least as far as I’m aware) that can be solved in the font.

The Regular Bold variant is rendered correctly by all programs. Is there anything different in the relationship between Regular and Regular Bold and the relationship between Semibold and Semilight that kenmcd provided ?

Shouldn't Semilight also be modified to point to Semibold as its Bold variant?

Or maybe older software do not understand fonts being part of more than one group ? So the bold variant of Semilight should be a standalone copy of Semibold named Semilight Bold.

[aaronbell]

Yes. There is no relationship between semilight and semibold. They’re just stand-alone instances cut from the variable font rather than designed for use in Office applications which require style-linking.

[kenmcd]

The Regular Bold variant is rendered correctly by all programs. Is there anything different in the relationship between Regular and Regular Bold and the relationship between Semibold and Semilight that kenmcd provided ?

It may be that NotePad++ (by using Scintilla for text rendering) only supports the old RIBZ font family model. And it may be looking at some "standard" weight and width settings, and it gets confused by anything outside of that old standard 400/700 (such as a Light weight of 300).

If you would like to test this theory... These are the Light, Light Italic, SemiBold, and SemiBold Italic fonts renamed and configured as an old RIBZ font family. The weights are set to the "standard" 400/700, and the width is still the standard 5 - but the fonts are still the same visually. The font base family is now named: CasCodeLight CassCodeLight.from.originals.2111.01.(2021-12-14).zip Four fonts: CasCodeLight-Regular (R) CasCodeLight-Italic (I) CasCodeLight-Bold (B) CasCodeLight-BoldItalic (Z)

So please try those in NotePad++ and see if they work.

I looked around in the NotePad++ tracker, and the Scintilla tracker and found nothing definitive regarding this, but there are other posts about issues with "non-standard" weights and widths, and some of the limitations of Scintilla. So this is the only "guess" I can think of which may work.

[CutterXYZ]

It works as expected !