Subset merging issue with Noto Naskh Arabic and Latin in gftools builder #1104

YusukeShirakihara · 2025-05-13T06:08:12Z

Hello. Thank you for developing such a powerful and helpful tool!

I’ve encountered an issue while trying to build some font family using gftools builder. I’ve already posted about it in the Noto Naskh Arabic repository, but I wanted to raise it here as well since it may be related to the tool itself.

When building Noto Naskh Arabic, it seems that the Latin subset (Regular weight) is being merged into all weights of Noto Naskh Arabic, regardless of the intended weight. This results in a mismatch between the Arabic and Latin components in the final font files.

I’m wondering:

Can we expect this to be adjusted in the gftools builder configuration or logic?
Or should this be now handled in the source files or build configuration of the font project itself?

Any guidance or clarification would be greatly appreciated!

Thanks again for your work on this project.

simoncozens · 2025-05-13T13:22:19Z

OK, the problem seems to stem here:

INFO:gftools.subsetmerger:Adding subset NotoSerif-Regular.ufo for location {'Weight': 700.0, 'Width': 100.0}

Here's what's happening:

Noto Naskh Arabic ranges from wght=400 to wght=700
Noto Serif has masters at wght=400 and wght=900, but it has a sparse master for some glyphs at wght=700. This sparse master is a layer of the Regular master UFO.
When gftools.subsetmerger looks for a wght=700 master to merge with the bold Naskh Arabic, it picks the sparse master.
Because it is a sparse master, only a few glyphs are varied in the Bold, and all the rest stay Regular.

We should probably pass over sparse masters when choosing a layer to merge. But in situations where there is a Semibold and a Black, picking the sparse master is absolutely the right thing to do. It's only when it's the extreme of a designspace that it should be skipped.

Goodness, this stuff is just so tricky.

simoncozens · 2025-05-13T15:36:00Z

Oh joy, it's even more tricky than that. I've managed to persuade it to ignore sparse masters which are not in the middle of the designspace. But now in this case, it drops down to using an instantiated UFO for the Bold (this is good!), but for some reason the Regular UFO (generated from Glyphs) has anchors propagated and the Bold UFO (instantiated from the designspace) does not!

simoncozens · 2025-05-13T15:50:55Z

In [23]: source_ds.sources[3].name, len(source_ds.sources[3].font["Kcommaaccent"].anchors)
Out[23]: ('Noto Serif Bold', 4)

In [24]: ufo = next(FontProject().interpolate_instance_ufos(source_ds, include="Noto Serif Bold"))
INFO:fontmake.font_project:Interpolating master UFOs from designspace
INFO:fontmake.font_project:Generating instance UFO for 'Noto Serif Bold'
INFO:fontmake.font_project:Saving ../sources/instance_ufo/NotoSerif-Bold.ufo

In [25]: len(ufo["Kcommaaccent"].anchors)
Out[25]: 2

WOT.

simoncozens · 2025-05-13T16:38:09Z

The root cause of this turns out to googlefonts/glyphsLib#1017
So we can't use instance UFOs to match "intermediate" layers, because anchor propagation happens differently for these.

YusukeShirakihara · 2025-05-14T01:03:05Z

Thank you so much for the detailed investigation and explanation!
It sounds like closing this issue would be the right step.
I really appreciate your support and valuable insights!

YusukeShirakihara closed this as completed May 14, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Subset merging issue with Noto Naskh Arabic and Latin in gftools builder #1104

Subset merging issue with Noto Naskh Arabic and Latin in gftools builder #1104

Subset merging issue with Noto Naskh Arabic and Latin in gftools builder #1104

Subset merging issue with Noto Naskh Arabic and Latin in gftools builder #1104

Comments