Repository navigation
Refactor YAML font definitions to reduce redundancy and improve structure #805
Description
While reviewing the current YAML file that defines font variations for Cascadia Code, Mono, NF, and PL, I noticed several areas where the structure can be improved for clarity, maintainability, and scalability.
Issues identified:
The wght and ital axis values are repeated across every font entry, despite being identical in nearly all cases.
Several font entries include the Italic axis even when the font doesn't support italic variants.
The file is long and harder to scan due to repetitive structures and inconsistent grouping by family (Code, Mono, etc.).
Any future change (e.g., modifying weight values) would require editing multiple sections manually, increasing the risk of inconsistency.
Suggested improvements:
Define shared axis values once at the top level (e.g., under shared_axes) and reference them in each font.
Remove unused axis definitions in font files that do not support certain features (e.g., Italic for Roman-only fonts).
Group font entries by family to make the file easier to navigate.
Use inline object notation where applicable to improve readability and reduce vertical sprawl.
Example structure:
shared_axes:
weight:
tag: wght
values:
- { name: ExtraLight, value: 200 }
- { name: Light, value: 300 }
- { name: SemiLight, value: 350 }
- { name: Regular, value: 400, linkedValue: 700, flags: 2 }
- { name: SemiBold, value: 600 }
- { name: Bold, value: 700 }
italic:
tag: ital
values:
- { name: Roman, value: 0, linkedValue: 1, flags: 2 }
- { name: Italic, value: 1 }
fonts:
-
file: CascadiaCode.ttf
axes: [weight, italic] -
file: CascadiaCodeItalic.ttf
axes: [weight, italic] -
file: CascadiaMono.ttf
axes: [weight]
This layout reduces repetition and makes it easier to maintain over time, especially as more font variants are added.
Next steps:
If there's interest in refactoring this, I can create a PR with the proposed changes and validate compatibility with the current processing system.
Let me know if this approach works, or if there's any constraint that requires the current structure.
Activity
[-]Feature Request[/-][+]Refactor YAML font definitions to reduce redundancy and improve structure[/+]aaronbell commentedon May 27, 2025
Thanks so much for the review and feedback! Honestly, at this point, Cascadia Code is being considered as "complete" barring a significant issue that needs resolution. Future development of this project will require a significant overhaul of the build system that will change pretty much everything, so I don't want you to spend your time working on something that will likely be replaced anyway!
kenmcd commentedon May 27, 2025
And the Italic axis in the Roman font is used by applications for style linking. Same in other VF fonts from GF and others. Not going to be removed.
theotrosman commentedon May 27, 2025
Hey, thanks a lot for the context and for clarifying the roadmap! Totally get it – makes sense to freeze things unless there's a critical bug.
If/when you kick off that big overhaul, hit me up! Would love to help test or contribute in any way I can.
Until then, I'll keep using Cascadia and spreading the word
Thanks for all the work and the transparency!
theotrosman commentedon May 27, 2025
Hey, thanks for the quick reply.
I get that a lot of VF fonts on Google Fonts and elsewhere use the Italic axis in this way, and it’s the established pattern for style linking. But I still think it’s worth reconsidering, or at least documenting the trade-offs for future devs/users.
Some environments and workflows don’t handle the Roman-Italic axis split very intuitively, especially in code editors or custom setups (the kind of places Cascadia Code usually shines).
Having a “dummy” Italic axis can be confusing for people trying to customize the font or automate workflows, and may lead to issues down the line if tooling changes.
Just because it’s the de facto method doesn’t always mean it’s the best approach for every project—especially a code-focused font like Cascadia, where clarity and customizability are key.
I’m not saying it must be changed, but at least a line in the docs explaining this choice and its reasoning could save future confusion (and a bunch of GitHub issues, tbh).
Appreciate all the work and the openness to discussion!