glifo: Add font embolden by jrmoulton · Pull Request #1628 · linebender/vello

jrmoulton · 2026-05-07T22:53:24Z

This PR bumps kurbo to latest main although it is currently a patch since peniko depends on the released kurbo 0.13. I can open a PR to peniko if we need to bump kurbo there first.

This PR adds support for font embolden by getting the value through to the new kurbo expand_path. The default embolden value is (0, 0). The chosen miter limit is 4.0 and the tolerance is 0.1. I'm not sure if these are the best values to use or if we should maybe make them configurable but these seem to be reasonable defaults.

@nicoburns

jrmoulton · 2026-05-07T23:38:48Z

I've also added support in vello classic

waywardmonkeys · 2026-05-08T02:15:11Z

@jrmoulton We want to make sure we're happy with this ... have some screenshots again? and then we'd do the publish of kurbo, peniko, update this PR, land it, and prep for a Vello family release.

jrmoulton · 2026-05-08T03:35:15Z

I'll get some screenshots posted

jrmoulton · 2026-05-08T04:21:49Z

I've exposed the join type, miter limit, and tolerance.

LaurenzV · 2026-05-08T06:06:37Z

+    pub embolden_x_bits: u64,
+    /// Synthetic embolden amount. Only non-zero for outline glyphs.
+    pub embolden_y_bits: u64,
+    /// Join style for synthetic embolden. Only meaningful for outline glyphs.
+    pub embolden_join_bits: u8,
+    /// Miter limit for synthetic embolden. Only meaningful for outline glyphs.
+    pub embolden_miter_limit_bits: u64,
+    /// Tolerance for synthetic embolden. Only meaningful for outline glyphs.
+    pub embolden_tolerance_bits: u64,


Could we not cast to f32 first and then store as u32 instead of u64? This would help with keeping the memory footprint of the glyph cache key smaller.

LaurenzV · 2026-05-08T06:08:21Z

        let packed = pack_color(BLACK);
-        let key1 = GlyphCacheKey::new(1, 0, 42, 16.0, true, 0.3, BLACK, packed, &[]);
-        let key2 = GlyphCacheKey::new(1, 0, 42, 16.0, true, 0.3, BLACK, packed, &[]);
+        let key1 = GlyphCacheKey::new(


I think this constructor is even more unwieldy now than it already was before now, would it make sense to group all emboldening-related keys into a custom struct?

I tried it but it seemed to be an awkward fit to construct the a struct just as a grouping for the cache key. It might be better to remove the new function and directly construct the key struct. That would be less unwieldy and ambiguous but since the new function was already there I opted to use it.

@taj-p @LaurenzV any more thoughts on this? I've added a new struct to group the font embolden on the glyph run builder but we can't use the same struct in the cache key because the cache key now uses f32. New struct or leave it as is?

actually I think I can just move the handling into the new function. that should work fine

Yeah I was overthinking that

LaurenzV · 2026-05-08T06:09:12Z

+    /// Set the synthetic embolden amount.
+    pub fn font_embolden(mut self, embolden: Diagonal2) -> Self {
+        self.run.font_embolden = embolden;
+        self
+    }
+
+    /// Set the join style for synthetic embolden.
+    pub fn font_embolden_join(mut self, join: Join) -> Self {
+        self.run.font_embolden_join = join;
+        self
+    }
+
+    /// Set the miter limit for synthetic embolden.
+    pub fn font_embolden_miter_limit(mut self, miter_limit: f64) -> Self {
+        self.run.font_embolden_miter_limit = miter_limit;
+        self
+    }
+
+    /// Set the tolerance for synthetic embolden.
+    pub fn font_embolden_tolerance(mut self, tolerance: f64) -> Self {
+        self.run.font_embolden_tolerance = tolerance;
+        self
+    }
+


Similarly, would it make sense to just create a FontEmboldenSettings struct and just a single setter for it?

I don't think so. This already has a fluent api for setting different properties. The naming is a bit unfortunate but I don't think adding a new struct with probably another fluent api would be better.

But I can do that if we decide to

I think it would be my preference, but yeah let's see what other's say.

This already has a fluent api for setting different properties.

Yes but they are all different properties, while the font embolden ones all refer to the same feature basically. Just like we also have a single Stroke struct instead of methods like set_stroke_width, set_stroke_miter_limit, etc.

If you're looking for another opinion, I think I prefer the separate struct version rather than inclining because it feels like how our other API is designed (collect into structs rather than inlining and flattening fields)

LaurenzV · 2026-05-08T06:43:08Z

Also, I think it would be great to have one or two tests for this in vello_sparse_tests.

taj-p

So good!!! Left some comments 🙏

Would be nice to have some tests as Laurenz suggested above

taj-p · 2026-05-08T18:52:17Z

-        outline.draw(draw_settings, &mut path).ok()?;
-        if path.finish(false) == 0 {
+        let n_path_segments = if self.embolden != Diagonal2::new(0.0, 0.0) {
+            let mut path = BezPathOutline(BezPath::new());


Should we maintain a reusable BezPath on the session so that we don't pay this allocation for every glyph?

taj-p · 2026-05-08T18:56:46Z

                outline_glyph.draw(draw_settings, &mut drawing_buf).unwrap();
+                if embolden != Diagonal2::new(0.0, 0.0) {
+                    drawing_buf.path = kurbo::expand_path(
+                        &drawing_buf.path,


It's unfortunate that the new method doesn't have a version that doesn't allocate.

It looks like expand_path always allocates a new BezPath internally - so we're paying an allocation per glyph when zero is possible.

I had a go of adding a re-useable context here linebender/kurbo#582

taj-p · 2026-05-08T18:58:23Z

+    /// Set the synthetic embolden amount.
+    pub fn font_embolden(mut self, embolden: Diagonal2) -> Self {
+        self.run.font_embolden = embolden;
+        self
+    }
+
+    /// Set the join style for synthetic embolden.
+    pub fn font_embolden_join(mut self, join: Join) -> Self {
+        self.run.font_embolden_join = join;
+        self
+    }
+
+    /// Set the miter limit for synthetic embolden.
+    pub fn font_embolden_miter_limit(mut self, miter_limit: f64) -> Self {
+        self.run.font_embolden_miter_limit = miter_limit;
+        self
+    }
+
+    /// Set the tolerance for synthetic embolden.
+    pub fn font_embolden_tolerance(mut self, tolerance: f64) -> Self {
+        self.run.font_embolden_tolerance = tolerance;
+        self
+    }
+


If you're looking for another opinion, I think I prefer the separate struct version rather than inclining because it feels like how our other API is designed (collect into structs rather than inlining and flattening fields)

jrmoulton · 2026-05-08T19:40:50Z

I added a snapshot test

nicoburns · 2026-05-10T22:12:31Z

@jrmoulton Git is complaining about this branch for me because the snapshot is not in git-lfs. I think you need to install Git LFS and then recommit the snapshot.

nicoburns · 2026-05-10T23:11:12Z

This is looking decent to me:

Left: Firefox on macOS. Right: Blitz on macOS with Vello Classic + this PR.

Embolden amount is computed as:

let embolden = kurbo::Vec2::new((0.015125 * font_size).min(0.3), (0.0121 * font_size).min(0.3));

where font_size is the font size in logical pixels.

Unless I'm missing something, this PR doesn't seem to wire through embolden into the vello_hybrid or vello_cpu APIs, so I am unable to test there.

Blitz PR for anyone who wants to try this out: DioxusLabs/blitz#428
Command to run is cargo run -rp browser

jrmoulton · 2026-05-11T01:11:46Z

Unless I'm missing something, this PR doesn't seem to wire through embolden into the vello_hybrid or vello_cpu APIs, so I am unable to test there.

The glyph run builder is provided by glifo. You can look at the snapshot test that uses vello cpu.

where font_size is the font size in logical pixels.

I had thought it was logical pixels but when I was testing I found it to be device pixels. I could have been wrong though

nicoburns · 2026-05-11T13:23:31Z

I had thought it was logical pixels but when I was testing I found it to be device pixels. I could have been wrong though

To be clear: I'm applying the formula to the unscaled font size, and applying the result as an embolden amount in physical pixels.

jrmoulton · 2026-05-12T23:01:15Z

@nicoburns I think I've fixed the git lfs issue

nicoburns

@jrmoulton This needs the kurbo crates.io patch removing, and an explicit dependency on kurbo v0.13.1 in both vello_encoding and glifo but has otherwise been judged to be good to land.

nicoburns · 2026-05-14T11:59:23Z

CI issues seems to be Swatinem/rust-cache#341

jrmoulton force-pushed the font-embolden branch from 8140ac9 to 095a200 Compare May 7, 2026 23:38

jrmoulton added 2 commits May 7, 2026 17:41

glifo: Add font embolden

4a6c1a7

vello classic: Support font embolden

9225f51

jrmoulton force-pushed the font-embolden branch from 095a200 to 9225f51 Compare May 7, 2026 23:41

expose the join, miter limit, and tolerance

887dd1a

LaurenzV reviewed May 8, 2026

View reviewed changes

truncate to f32 for smaller cache key

2546af5

jrmoulton force-pushed the font-embolden branch from 9e47b3c to 2546af5 Compare May 8, 2026 16:46

taj-p reviewed May 8, 2026

View reviewed changes

jrmoulton force-pushed the font-embolden branch from 132b92a to 60eb43e Compare May 8, 2026 19:23

add FontEmbolden struct for glyph builder

4096e53

jrmoulton force-pushed the font-embolden branch from 60eb43e to 4096e53 Compare May 8, 2026 19:26

sparse tests: Add emboldened glyph snapshot

dd50e03

taj-p mentioned this pull request May 8, 2026

Add reuseable context to new expand_* functions linebender/kurbo#582

Open

jrmoulton force-pushed the font-embolden branch from 1cf944e to dd50e03 Compare May 12, 2026 23:00

nicoburns approved these changes May 13, 2026

View reviewed changes

set kurbo to released version

0adf1cd

nicoburns added this pull request to the merge queue May 14, 2026

Merged via the queue into linebender:main with commit b5b3e06 May 14, 2026
45 of 51 checks passed

Conversation

jrmoulton commented May 7, 2026

Uh oh!

jrmoulton commented May 7, 2026

Uh oh!

waywardmonkeys commented May 8, 2026

Uh oh!

jrmoulton commented May 8, 2026

Uh oh!

jrmoulton commented May 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jrmoulton May 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LaurenzV commented May 8, 2026

Uh oh!

taj-p left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jrmoulton commented May 8, 2026

Uh oh!

nicoburns commented May 10, 2026

Uh oh!

nicoburns commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jrmoulton commented May 11, 2026

Uh oh!

nicoburns commented May 11, 2026

Uh oh!

jrmoulton commented May 12, 2026

Uh oh!

nicoburns left a comment

Choose a reason for hiding this comment

Uh oh!

nicoburns commented May 14, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

jrmoulton May 8, 2026 •

edited

Loading

nicoburns commented May 10, 2026 •

edited

Loading