Bold characters are wider than regular ones when using the Light or SemiLight variants about cascadia-code HOT 16 OPEN

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

from cascadia-code.

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.

from cascadia-code.

It works as expected !

from cascadia-code.

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".

from cascadia-code.

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++

from cascadia-code.

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

from cascadia-code.

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

from cascadia-code.

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.)

from cascadia-code.

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

from cascadia-code.

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.

from cascadia-code.

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.

from cascadia-code.

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.

from cascadia-code.

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.

from cascadia-code.

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.

from cascadia-code.

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.

from cascadia-code.

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.

from cascadia-code.