-
Notifications
You must be signed in to change notification settings - Fork 801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bold characters are wider than regular ones when using the Light or SemiLight variants #713
Comments
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". |
Unfortunately this is a software limitation and not something (at least as far as I’m aware) that can be solved in the font. |
In my response, Eclipse is a representative example. Font family member mapping problems are not unique to Eclipse 😄 |
|
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
WorkingBroken¹ (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.) |
It is really quite sad, so many years after the introduction of variable fonts, that app support is still so abysmal. |
Eclipse is indeed showing the Light version of the character and apparently applying some "bold" format to it. |
Of course it does not work... 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. 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. |
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. |
These are the SemiBold static fonts style-linked to the Light fonts. Your application must be able to understand multiple RIBBI style groups correctly. You cannot have the variable fonts installed at the same time. Light is your "Regular" and SemiBold is your "Bold". |
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. |
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. |
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. |
It may be that NotePad++ (by using Scintilla for text rendering) only supports the old RIBZ font family model. If you would like to test this theory... 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. |
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:
![image](https://private-user-images.githubusercontent.com/29694177/300474338-c46fb795-9f69-4f27-a807-d745acf79224.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjMwNjE3ODgsIm5iZiI6MTcyMzA2MTQ4OCwicGF0aCI6Ii8yOTY5NDE3Ny8zMDA0NzQzMzgtYzQ2ZmI3OTUtOWY2OS00ZjI3LWE4MDctZDc0NWFjZjc5MjI0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODA3VDIwMTEyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWFkYzVhNGJlNmM1ZTllOWE0Y2FlYzM1OWEzZGY2NTgwYTg4NGU5YjZiNWY4N2VmNzE0Y2I0MDkxNzg5NzExODMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.CR6689iNMbI8ZUo3ZEHbW1KEcAcYisJv_uudNhYSaro)
In MS Word, there is no difference in width but bold SemiLight text is rendered strangely:
![image](https://private-user-images.githubusercontent.com/29694177/300475651-1e7f6b91-1b9d-4460-ad45-58f0d26dbf60.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjMwNjE3ODgsIm5iZiI6MTcyMzA2MTQ4OCwicGF0aCI6Ii8yOTY5NDE3Ny8zMDA0NzU2NTEtMWU3ZjZiOTEtMWI5ZC00NDYwLWFkNDUtNThmMGQyNmRiZjYwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MDclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODA3VDIwMTEyOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWQ1MWZmNzc4MTEzMDRkZDc0MGJiZjhlZjdmYmY2OTY3ZDdiOTVhYzg3NWRhMzI0NDFjMzUxZDgwODA1NGU1OWEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.fdF7L6Pp8ANPXl90Y24ZdaGPKAvvt-VHpu1_qIOWz_k)
The text was updated successfully, but these errors were encountered: