icon_names subset produces glyphs with wrong stroke/fill state vs un-subset...
Material Design icons by Google (Material Symbols)
Brought to you by:
tomkozak
Menu
▾
▴
Milestone
Searches
Help
#1997 icon_names subset produces glyphs with wrong stroke/fill state vs un-subset font (v345)
Originally created by: ronapelbaum2
Summary
When fetching Material Symbols Rounded from Google Fonts using the icon_names=... subsetting parameter with a large list of icons (~400 names), the resulting subset font renders glyphs at a different stroke / fill state than the un-subset full font, regardless of the font-variation-settings the consuming CSS specifies.
This appears to be a recurrence of the class of bugs already filed against icon_names subsetting, including:
- [#1834] — "Loading only specific icons using icon_names parameter does not work properly when using the table icon" (open since 2024-11-08)
- [#1818] — "Can't use star and tour icons at the same time" (open since 2024-10-17)
I'm filing a separate report because the manifestation here is "wrong glyph weight / fill" rather than "icon missing," and triggers on a different icon list. Same underlying area of code, different symptom.
Versions involved
- Material Symbols Rounded internal Google Fonts version:
v344→v345 - Bug observable starting on/around 2026-05-22 → 2026-06-02 (matches the public Material Symbols Changelog update window).
- The bug is in the subsetted font response. The un-subset (full) font fetched from
fonts.gstatic.com/s/materialsymbolsrounded/v345/...renders correctly at both v344 and v345.
Reproduction
Two minimal HTML files. Both request the same family, axes, and CSS — the only difference is the presence of &icon_names=.... Open both side by side in the same browser.
A — uses icon_names (broken)
<!doctype html><html><head><meta charset="utf-8"><title>A — subset</title>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Rounded:opsz,wght,FILL,GRAD@24,300,0..1,0&icon_names=access_time,account_balance,account_balance_wallet,...HUNDREDS_OF_ICON_NAMES...,zoom_out_map&display=swap">
<style>
.btn{display:inline-grid;place-items:center;width:36px;height:36px;border-radius:999px;background:#234;color:#fff}
.icon{font-family:'Material Symbols Rounded';font-weight:normal;font-size:20px;line-height:1;
-webkit-font-feature-settings:'liga';-webkit-font-smoothing:antialiased;
font-variation-settings:'FILL' 0,'wght' 300,'GRAD' 0,'opsz' 24}
</style></head><body>
<span class="btn"><span class="icon">settings</span></span>
<span class="btn"><span class="icon">question_mark</span></span>
</body></html>
The full icon list I used (alphabetical, ~400 names) is available [in this gist or PR / I can attach if useful]. A small two-icon list (just settings,question_mark) does not reproduce the bug — it requires a large icon set.
B — no icon_names (correct)
Same HTML as A, but the stylesheet link drops &icon_names=...:
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Material+Symbols+Rounded:opsz,wght,FILL,GRAD@24,300,0..1,0&display=swap">
Observed difference
The cog (settings) glyph in A renders with a noticeably thinner stroke / lower visual weight than in B, even though both ask for 'wght' 300, 'FILL' 0 and both ultimately resolve to the same family. The ? (question_mark) glyph is harder to distinguish visually.
The Network panel confirms different font paths:
- A:
fonts.gstatic.com/l/font?kit=…&v=v345(size ~570 KB) — the "l" dynamic-subset path. - B:
fonts.gstatic.com/s/materialsymbolsrounded/v345/...— the "s" canonical full-font path.
Direct font inspection (fontTools)
The subset font is structurally identical in shape between v344 and v345, just with +9 ligatures (matching the public changelog):
v344 woff2: 567,284 bytes, sha 7c18d84d96fa350ec33c2f4bc0080babd52a8785
cmap=31 chars, 4064 ligatures, features [rclt, rlig]
v345 woff2: 570,032 bytes, sha af3433aee2663cc9f14c65efdec9650e186e7c7c
cmap=31 chars, 4073 ligatures, features [rclt, rlig]
Both have the same OpenType table shape; what changed between v344 and v345 in the subsetted woff2 is the glyf / gvar / variation-axis data, in a way that interacts with our requested axes and produces wrong rendering.
Why this matters
This bug is shipping to production for any app that uses the documented icon_names subsetting parameter (recommended by your Material Symbols guide) with a sufficiently large icon list. The bug is non-deterministic-from-the-app's-perspective: a Google-side font version rollout can break a deployed product without any change in the app's repo. Build pipelines that inline Google Fonts CSS at build time (e.g. Angular CLI's optimization.fonts: true) bake the broken subset into the production artifact.
We've worked around it by removing icon_names from our font request and accepting the larger full-font payload. Self-hosting is our follow-up. But this should be a real fix on Google's side, given the documented icon_names feature is supposed to be safe.
What would help
- Acknowledgment of the bug.
- Either a fix in the
icon_namessubsetter, or a documented disclaimer on the Material Symbols guide noting that theicon_namessubset can render axes differently than the full font. - Optionally: an opt-out parameter to force
font-variation-settings-honoring behavior in the subset.
Cross-references
- [#1834] (open, 2024-11-08)
- [#1818] (open, 2024-10-17)
- Material Symbols Changelog showing the v344→v345 window: https://material-symbols-changelog.vercel.app/
Related
Originally posted by: tphinney
I hate to ask for more when you have already documented so much, but could you possibly provide screen shots for case (A) (and B for comparison)?