Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Manrope woff2 name tables say "Manrope ExtraLight" (woff files are correct)

Open
#162 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
javascript, python

Research direction

Start by reading the generated files/manrope-latin--normal.woff2 and comparing their name tables with the matching .woff files. Use the provided fontTools snippet to verify name IDs 1, 2, 4, and 6, then trace the instancing pipeline to determine whether the typographic family and instance style are preserved. Done means the WOFF2 names match the WOFF names without changing outlines or weights, with other affected families checked.

Written by the indexing model from the issue text.

Description

Summary

The .woff2 files in @fontsource/[email protected] declare their internal family name as Manrope ExtraLight. The .woff files of the same weights are named correctly. Since browsers prefer woff2, every tool that reads a font's name table — Font Ninja, Figma importers, design-handoff plugins, asset catalogues — reports the page as using Manrope ExtraLight.

Outlines and usWeightClass are correct, so pages render correctly and weights measure distinctly. Only the name is wrong, which is what makes it hard to find.

Evidence

Name table, platform 3, read from files/manrope-latin-<weight>-normal.woff2:

CSS weight family(1) subfamily(2) postScript(6) typoFamily(16)
400 Manrope ExtraLight Regular ManropeExtraLight-Regular —
500 Manrope ExtraLight Medium Regular ManropeExtraLight-Medium Manrope ExtraLight
600 Manrope ExtraLight SemiBold Regular ManropeExtraLight-SemiBold Manrope ExtraLight
700 Manrope ExtraLight Bold ManropeExtraLight-Bold —
800 Manrope ExtraLight ExtraBold Regular ManropeExtraLight-ExtraBold Manrope ExtraLight

The same weights in .woff are correct: Manrope, Manrope Medium, Manrope SemiBold, Manrope/Bold, Manrope ExtraBold.

Chrome confirms it. CSS.getPlatformFontsForNode on a page using these files:

"Dashboard"      weight=600 → Manrope ExtraLight SemiBold   9 glyphs  webfont
"Residents"      weight=500 → Manrope ExtraLight Medium     9 glyphs  webfont
"Rosewood Court" weight=700 → Manrope ExtraLight           14 glyphs  webfont

Likely cause

Upstream. Google's ofl/manrope/Manrope[wght].ttf declares family(1) = "Manrope ExtraLight", postScript(6) = "Manrope-ExtraLight", usWeightClass 200, with a wght axis of min 200, default 200, max 800 — name IDs 1 and 2 describe a variable font's default instance, and Manrope's default is ExtraLight. Google's own METADATA.pb records full_name: "Manrope ExtraLight" for the entry it lists at weight 400.

So an instancer that derives name ID 1 from the source without overriding it produces Manrope ExtraLight <Weight>. The .woff pipeline apparently sets names differently, which is why the two formats disagree.

I have filed the upstream half separately; this is not solely a Fontsource bug, but Fontsource is where most people meet it.

Suggested fix

When instancing, set name IDs 1/2/4/6 from the typographic family (Manrope) plus the instance style, rather than inheriting the default instance's legacy name. Worth checking whether other families built from variable sources with a non-Regular default are affected the same way.

Reproducing

// read the name table out of the woff2 directly
const { brotliDecompressSync } = require('node:zlib')
// ... walk the WOFF2 table directory, brotli-decompress, read table 'name'

Or with fontTools:

from fontTools.ttLib import TTFont
f = TTFont('files/manrope-latin-600-normal.woff2')
print({r.nameID: str(r) for r in f['name'].names if r.platformID == 3}[1])
# 'Manrope ExtraLight SemiBold'
Dominant language
CSS
Stars
500
Forks
72
Avg merge
22h 49m
Merged PRs (30d)
2

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fontsource/font-files

All issues in fontsource/font-files

Similar issues

More Build System issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.