Weight axis issue building with new gftools

[alerque]

I think we ran into this on Raleway too, but one of the things we're doing as part of Fontship’s build process is using the normalization and fixup tools in gftools (Google Fonts' toolkit). It has gotten a little bit stricter since we released v2.210. If still builds with the old Docker image of Fontship (v0.3.4), but trying to upgrade it to anything newer (such as the current v0.5.0 or master branch) fails:

File "/usr/bin/gftools-fix-vf-meta.py", line 167, in update_nametable
raise ValueError(f"Unsupported wght coord '{wght_val}'. Coord "
ValueError: Unsupported wght coord '277.0'. Coord needs to be in {WGHT.keys()}

[alerque]

Hmm, it wasn't Raleway, it was this font and it came up here.

[alerque]

This has something to do with this:

league-spartan/sources/LeagueSpartan.glyphs

Lines 56 to 70 in 4b19a40

	{
	name = "Axis Mappings";
	value = {
	wght = {
	200 = 200;
	277 = 300;
	350 = 400;
	500 = 500;
	600 = 600;
	700 = 700;
	800 = 800;
	900 = 900;
	};
	};
	}

If I make the two oddball mappings here 200 = 200 and 400 = 400 everything builds fine. I can't (yet) find another combination of values or way to work around this.

[alerque]

Clearly my hack to make this work before wasn't the right solution. This was discussed at length in this glyphsLib issue. I'm still not sure what the right fix is here, but links from that discussion should help.

[alerque]

It looks like my old fix was just backwards — and yes this changed in fontmake and hence the trickle down to checks in gftools. Instead of inventing imaginary design coordinates to swapping the Axis Mappings so that user coordinates map to design coordinates (instead of the other way around).

[alerque]

Arg! This is not right. It builds fine, but some experimenting with the static instances as generated now show that they are not an even map now. In v2.210 this was a straight line, now it's not:

SILE Code

\begin[papersize=a6]{document}
\nofolios
\neverindent
\begin{raggedright}
\begin{script}
for weight=200, 800, 100 do
	SU.debug("foo", weight)
	SILE.call("font", {
		family = "League Spartan",
		weight = weight,
		features = "+tnum"
	}
	{ "abcdefghijklmnopqrstuvwxyz League Spartan "..weight })
	SILE.call("break")
end
\end{script}
\end{raggedright}
\end{document}

@sursly Can you take a look at this again? The hack I made on the Glyphs source before we released v2.210 no longer builds using the latest tooling (fontmake + gftools), which is now the current tooling under the hood in fontship. I've swapped out that hack for another one that now builds again, but given the output above I'm pretty sure it's actually broken. Can you branch off the current master and have a look at this is Glyphs again? Given the discussion I saw between Glyphs developers and Google I suspect the output of Glyphs might actually have changed so that these all work together now, but the sources for this font need fixing so your weight axis adjustment works as intended.

[alerque]

For reference the old hack revert is at 243cd9e and the new hack I added is ad13b58. If you want to get back to the original without either of my hacks and work from there, git revert ad13b58 will get you there.

[alerque]

I've taken another stab at fixing this myself, see #31.

[sursly]

OK, using the latest gftools and fontmake, my version builds fine 👍 I did normalize the weight values for the instances so they are linear (as you did in #31 ) and properly indicate that 900 is black. Think we can close this and I'll see you in the other issue.