Apply preferred font weight when loading variable fonts by pmnxis · Pull Request #7790 · emilk/egui

pmnxis · 2025-12-18T15:26:38Z

Previously, when loading a variable font (e.g. via egui::FontData::from_static),
the font was rendered using the default (often the lightest) weight,
ignoring any preferred weight configuration.

This change applies the specified weight to skrifa's Location for the wght axis,
ensuring that variable fonts are rendered with the intended font weight.

Summary

Fixes variable font weight not being applied during rendering. The FontData::weight() method now properly configures the font variation axis.

Changes

Add location: Location field to FontFace to store variation coordinates
Pass location parameter through to glyph rendering functions
Apply weight to skrifa's LocationRef in DrawSettings and HintingInstance

Weight Priority

preferred_weight from FontData::weight()
OS/2 table's us_weight_class
Variable font's fvar default value
Location::default()

Related Issue

add Fontweight to fontid #3218 : Not follow font id, but goal would be same

Todo

Apply preferred font weight when loading variable fonts
Add small size variable fonts for docs and egui (need discussion)

Previously, the `FontData::weight()` method stored the preferred weight but it was never applied to the actual font rendering. This change uses the weight value to configure skrifa's Location for the 'wght' axis, enabling proper variable font weight control in text rendering.

github-actions · 2025-12-18T15:26:47Z

Preview available at https://egui-pr-preview.github.io/pr/7790-featurefont-weight-0333
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

View snapshot changes at kitdiff

When loading variable fonts in egui, the first available weight was selected instead of the font’s default weight, making it impossible to control the rendered weight. This change applies the preferred weight (or the font’s default value) to the `wght` axis, ensuring variable fonts are rendered with the intended weight. Related PR: emilk/egui#7790

emilk

Nice - thanks!

emilk · 2025-12-19T17:44:20Z

Do you want to do this before I hit merge?

pmnxis · 2025-12-19T18:05:32Z

@emilk
Checkpoint “Add small size variable fonts for docs and egui (need discussion)”,

https://github.com/emilk/egui/pull/7790/files#diff-476cc9a474dfda61ceeb981bd3ea229a1ab4eb65330e74c0128ce257236938c9R177-R187
In this PR , the new docs code uses UbuntuLight instead of some variable font.

Ideally, it would be better to include a variable font directly in the source tree and add
some verification code to ensure that variable fonts actually work as expected.
I have already validated this approach in my own project:
https://github.com/pmnxis/chama-optics

That said, adding variable fonts would significantly increase the source tree size,
so keeping the existing example as-is also seems like a reasonable choice.

Previously, when loading a variable font (e.g. via `egui::FontData::from_static`), the font was rendered using the default (often the lightest) weight, ignoring any preferred weight configuration. This change applies the specified weight to skrifa's `Location` for the `wght` axis, ensuring that variable fonts are rendered with the intended font weight. ## Summary Fixes variable font weight not being applied during rendering. The `FontData::weight()` method now properly configures the font variation axis. ## Changes - Add `location: Location` field to `FontFace` to store variation coordinates - Pass `location` parameter through to glyph rendering functions - Apply weight to skrifa's `LocationRef` in `DrawSettings` and `HintingInstance` ## Weight Priority 1. `preferred_weight` from `FontData::weight()` 2. OS/2 table's `us_weight_class` 3. Variable font's fvar default value 4. `Location::default()` ## Related Issue - emilk#3218 : Not follow font id, but goal would be same ## Todo * [x] Apply preferred font weight when loading variable fonts * [ ] Add small size variable fonts for docs and egui (need discussion)

valadaptive · 2025-12-26T20:14:41Z

I'm a bit confused by this PR. When will a variable font's default weight be the "lightest" one? By definition, the default value for any axis should be mapped to 0.0 in variation space, which is what Skrifa uses if you don't specify any coordinates.

This PR changes the font loading process to use the weight value from the OS/2 table if present, but falls back to the default wght axis value from the fvar table if not, which is...exactly what we were doing before.

Can you give examples of variable fonts that default to the lightest weight? Are they fixed if you use the weight from the OS/2 table, or do you still need to manually override the weight when loading them?

pmnxis · 2026-01-02T13:09:14Z

@valadaptive

Can you give examples of variable fonts that default to the lightest weight?
The Noto CJK variable fonts are an example:
https://github.com/notofonts/noto-cjk/tree/main/google-fonts

After re-examining the OS/2 table, I confirmed that these fonts have
<usWeightClass value="100"/>, which explains why they default to the lightest weight. And I mistaked I didn't checked well it.

That said, there are still cases where manually overriding the font weight is necessary.
In those situations, the function I mentioned in your PR, pub fn weight(self, weight: u16) -> Self is still allowed by your changes, and I’ve confirmed that it correctly covers this use case.

const FONT_NTSANS: BuiltInFonts = BuiltInFonts {
    name: "Noto Sans",
    data: include_bytes!("../../assets/fonts/NotoSansJP[wght].ttf"),
};

// Demonstrates how to replace all fonts.
pub(crate) fn replace_fonts(ctx: &egui::Context) {
    let mut fonts = egui::FontDefinitions::default();

    fonts.font_data.insert(
        FONT_NTSANS.name.to_owned(),
        std::sync::Arc::new(egui::FontData::from_static(FONT_NTSANS.data).weight(400)),
    );
    
    ctx.set_fonts(fonts);
}

* Closes N/A * [x] I have followed the instructions in the PR template This appears to have snuck in as part of #7790, which claimed to only be a bugfix but introduced a new `font_weight` method. I believe there's no way to access the method from *public* code since it's only defined on `FontsImpl`, not the public-facing `FontsView`. It's also not used *privately* in epaint, meaning it's completely dead code. Even if we *do* want some sort of future API for getting a font's weight, it requires more consideration. For instance, this API will return the default weight for variable fonts, which is not documented anywhere and might not be what we want.

* Closes N/A * [x] I have followed the instructions in the PR template This was mostly from last month, but I never got around to submitting it. This PR adds font variation coordinates to the `TextFormat` struct, and uses them when rendering text. The coordinates are stored in a `SmallVec`; I've chosen to store up to 2 inline, which makes it take up 24 bytes (the minimum possible for a `SmallVec`). The variation axis tags are stored as the `font_types::Tag` type, which I've chosen to re-export from `epaint::text`. The variation coordinates are resolved to a `skrifa::Location` during font rendering/scaling, and are cached in the same way as all the other scaled metrics. I've renamed the `ScaledMetrics` struct to `StyledMetrics`, since it now also contains the resolved variation coordinates. I haven't benchmarked the performance of text layout with variation coordinates, but the existing text layout performance is unchanged. I've replaced the API for manually overriding a font's weight (#7790) with an API for manually overriding any variation coordinates via `FontTweak`. This should support the same use case as #7790 while being substantially more flexible. I have *not* yet added any higher-level API for mapping style attributes (weight, width, slant, etc) to variation coordinates or to different font faces within a single family. That's a pretty huge can of worms, and it'd involve rethinking the split between `FontId` and `TextFormat` (and whether `FontId` is so big that we should provide a way to reuse it). This API is intentionally pretty low-level for now. Likewise, I've intentionally not used variation coordinates when computing a font's row height. I can't think of any fonts that change their vertical metrics depending on variation axes, so this should be fine for now. --------- Co-authored-by: Emil Ernerfeldt <[email protected]>

Previously, when loading a variable font (e.g. via `egui::FontData::from_static`), the font was rendered using the default (often the lightest) weight, ignoring any preferred weight configuration. This change applies the specified weight to skrifa's `Location` for the `wght` axis, ensuring that variable fonts are rendered with the intended font weight. Fixes variable font weight not being applied during rendering. The `FontData::weight()` method now properly configures the font variation axis. - Add `location: Location` field to `FontFace` to store variation coordinates - Pass `location` parameter through to glyph rendering functions - Apply weight to skrifa's `LocationRef` in `DrawSettings` and `HintingInstance` 1. `preferred_weight` from `FontData::weight()` 2. OS/2 table's `us_weight_class` 3. Variable font's fvar default value 4. `Location::default()` - emilk#3218 : Not follow font id, but goal would be same * [x] Apply preferred font weight when loading variable fonts * [ ] Add small size variable fonts for docs and egui (need discussion)

* Closes N/A * [x] I have followed the instructions in the PR template This appears to have snuck in as part of emilk#7790, which claimed to only be a bugfix but introduced a new `font_weight` method. I believe there's no way to access the method from *public* code since it's only defined on `FontsImpl`, not the public-facing `FontsView`. It's also not used *privately* in epaint, meaning it's completely dead code. Even if we *do* want some sort of future API for getting a font's weight, it requires more consideration. For instance, this API will return the default weight for variable fonts, which is not documented anywhere and might not be what we want.

* Closes N/A * [x] I have followed the instructions in the PR template This was mostly from last month, but I never got around to submitting it. This PR adds font variation coordinates to the `TextFormat` struct, and uses them when rendering text. The coordinates are stored in a `SmallVec`; I've chosen to store up to 2 inline, which makes it take up 24 bytes (the minimum possible for a `SmallVec`). The variation axis tags are stored as the `font_types::Tag` type, which I've chosen to re-export from `epaint::text`. The variation coordinates are resolved to a `skrifa::Location` during font rendering/scaling, and are cached in the same way as all the other scaled metrics. I've renamed the `ScaledMetrics` struct to `StyledMetrics`, since it now also contains the resolved variation coordinates. I haven't benchmarked the performance of text layout with variation coordinates, but the existing text layout performance is unchanged. I've replaced the API for manually overriding a font's weight (emilk#7790) with an API for manually overriding any variation coordinates via `FontTweak`. This should support the same use case as emilk#7790 while being substantially more flexible. I have *not* yet added any higher-level API for mapping style attributes (weight, width, slant, etc) to variation coordinates or to different font faces within a single family. That's a pretty huge can of worms, and it'd involve rethinking the split between `FontId` and `TextFormat` (and whether `FontId` is so big that we should provide a way to reuse it). This API is intentionally pretty low-level for now. Likewise, I've intentionally not used variation coordinates when computing a font's row height. I can't think of any fonts that change their vertical metrics depending on variation axes, so this should be fine for now. --------- Co-authored-by: Emil Ernerfeldt <[email protected]>

emilk approved these changes Dec 19, 2025

View reviewed changes

emilk added egui epaint labels Dec 19, 2025

emilk merged commit 646fea2 into emilk:main Dec 19, 2025
27 of 28 checks passed

valadaptive mentioned this pull request Dec 26, 2025

Remove font_weight API #7811

Merged

1 task

valadaptive mentioned this pull request Jan 23, 2026

Add font variations API #7859

Merged

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Apply preferred font weight when loading variable fonts#7790

Apply preferred font weight when loading variable fonts#7790
emilk merged 1 commit intoemilk:mainfrom
pmnxis:feature/font-weight-0.33.3

pmnxis commented Dec 18, 2025

Uh oh!

github-actions bot commented Dec 18, 2025 •

edited

Loading

Uh oh!

emilk left a comment

Uh oh!

emilk commented Dec 19, 2025

Uh oh!

pmnxis commented Dec 19, 2025

Uh oh!

Uh oh!

valadaptive commented Dec 26, 2025 •

edited

Loading

Uh oh!

pmnxis commented Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

pmnxis commented Dec 18, 2025

Summary

Changes

Weight Priority

Related Issue

Todo

Uh oh!

github-actions bot commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

emilk left a comment

Choose a reason for hiding this comment

Uh oh!

emilk commented Dec 19, 2025

Uh oh!

pmnxis commented Dec 19, 2025

Uh oh!

Uh oh!

valadaptive commented Dec 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pmnxis commented Jan 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions bot commented Dec 18, 2025 •

edited

Loading

valadaptive commented Dec 26, 2025 •

edited

Loading