What is the purpose of so many Advance Width entries in SMuFl fonts .json files (other than Bravura)? Doesn’t Dorico use the BBboxes and anchors for most of the non-textual symbols? E.g. why would “noteheadBlack“ need advance width, if it has zero-bearings and stemUP/Down anchors? I notice that most of the glyphs simply duplicate their metric width as advance width.
Think of advanceWidth in SMuFL as the glyph’s “cursor step.” It tells the layout engine how far to move to the right after drawing a glyph when that glyph is being used in a text-like line of symbols. So it’s not really about Dorico’s engraving spacing rules for notes.
Dorico does position a lot of musical symbols using anchors (for attachments like stems) and sometimes glyph bounds (for collision/spacing decisions). But advanceWidth still comes into play any time Dorico is laying symbols out in a simple left-to-right run, using more general “typesetting” logic. That happens when SMuFL symbols show up inline in things like music text, playing techniques, chord/figure-like strings, or user-entered symbol sequences—places where Dorico needs a reliable way to move from one glyph to the next without special-case engraving rules for every character.
It’s also useful when symbols are built from multiple glyphs placed in a row—combined signs, repeated patterns, or notations assembled on the fly. In those cases, advanceWidth is the straightforward, font-native way to get consistent spacing between the pieces.
Zooming out, SMuFL isn’t just for Dorico. It’s designed to work across lots of apps and workflows. Even if Dorico often uses anchors and bounds, other SMuFL users (and even some fallback paths inside Dorico) may still rely on advanceWidth. Including it widely makes the font more predictable and compatible.
That’s why even something like noteheadBlack can have an advanceWidth: it might appear inline in a text-like context, or be handled by code that expects a defined advance—even though, in “normal” engraving, the notehead’s relationship to the stem is handled via anchors. Anchors tell you where things attach; they don’t tell you how far to advance to the next glyph.
And finally, zero side bearings, bounding boxes, and anchors don’t replace advanceWidth. Bearings tell you how the outline sits around the origin, the bbox tells you what area the glyph occupies, and anchors define attachment points—but none of those says where the next glyph should start. So many glyphs end up with advanceWidth that closely matches their metric width simply because that’s standard font behavior and produces stable text-style layout. SMuFL metadata just makes those values explicit so apps don’t have to guess.
Hope that helps!
14 Likes
*checks long answer about SMuFL
*sees it’s written by @NorFont.com
*reads whole thing twice and takes notes 
10 Likes
Haha, glad it was useful!
Thanks Nor. Please correct me if I’m wrong.
I don’t think this is correct. Bearings (LSB and RSB) define margins within the bounding box, i.e. how far from the origin the glyph begins and how much space there is after the glyph ends. They can be either positive or negative, and they are exactly what is used for spacing inline characters (before kerning), defining where the next glyph should start.
In your example of a noteheadBlack, the stem placement is handled by anchors, but note spacing still uses the character’s width. It doesn’t need Advance Width to achieve this.
I guess, my question is: what problem is Adavance Width trying to solve, beyond what’s already available directly in the font file? Otherwise, how word processors would work?
That’s a fair question. My earlier wording was a bit too broad. A normal word processor doesn’t need SMuFL metadata at all — it reads advance widths (and kerning/shaping) directly from the font. SMuFL’s glyphAdvanceWidths isn’t inventing a new spacing concept; it’s exposing the font’s advance widths in a standardized, app-friendly form: per SMuFL glyph name and expressed in staff spaces for consistent use in notation/text workflows.
Per the spec, the advance width is origin-to-origin, includes positive side-bearings, and doesn’t include outline protrusions (negative side-bearings). That’s not “missing where the next glyph starts” — the next origin is still defined by the advance — it just allows overhangs beyond the step (useful for tighter visual combinations like fff, then refined further by kerning/ligatures if needed).
And yes: Dorico’s rhythmic spacing for notes doesn’t need glyphAdvanceWidths, but glyphAdvanceWidths remains useful whenever symbols are laid out as simple left-to-right runs (music text, symbol strings, composites, and interoperability across SMuFL consumers).
3 Likes
This is an excellent explanation, I finally understand the purpose, thank you. I’ve revised my generate_font_metadata.py to include glyphAdvanceWidths. It was quite confusing that the original scripts didn’t include this.
1 Like
Glad that clicked!
One small tip: just make sure the conversion to staff spaces is consistent with your SMuFL units/em setup, and don’t try to “correct” negative overhangs into advance width — those belong in side-bearings/outline behavior, not the origin-to-origin step.
2 Likes
Yes, I just converted the widths to SMuFL “staff-space” units. It matches how it’s represented in bravura.json.
1 Like