Sanity check: ensure linked values exist within the same axis in Stylespace

[twardoch]

But linked values can be in a different font, no? Like italic=1 can be in a separate italic VF, and of course in static fonts all values can be somewhere else.

[madig]

But it must exist in the Stylespace at least, because the Stylespace must contain everything.

[twardoch]

This sounds like you're imposing the principle that the same stylespace is used for all fonts and statmake magically subsets it. But that's not the only use case. People may think of each stylespace as being per font and produce it themselves. Statmake works in this case.

A warning may be ok but please don't make it a no-go.

[madig]

This sounds like you're imposing the principle that the same stylespace is used for all fonts and statmake magically subsets it.

That's actually the founding principle of statmake, because the STAT table is supposed to describe the entire family, not each font individually. I can't even think of a use-case where linked values exist outside a Stylespace?

[twardoch]

I understood the founding principle but it happened that I originally didn't see it, and I wrote my stylespaces like they're just user friendly STAT reprs, one per designspace. And you remember I asked for a way to express the whole stylespace in the designspace for a lib.

And this all works, too. Which is good, because the point is — you may not necessarily at one point know the extent of all designspaces. Say I'm making a family to which I know I'll add condensed later but I haven't decided. So I'll put wdth = 100 in the current stylespace, but I won't make a real master stylespace yet. I keep it to what I know. This is not right now about the linking, just the "master stylespace" concept.

I may add the cndenseds later, or italics. Yes, I could extend the master stylespace or I could make a dedicated stylespace for those.

Point being: there's use-cases for multiple per-designspace stylespaces. And those, if I choose to work that way, may be perfectly workable. But if I do them this way, while parsing a stylespace, same font won't apply.

But I think you're right that those multi-stylespaces should have their bounds set correct if I use linking. So a check for "linked value is in bounds" is Ok I think. Just not the "same font" thing :)

[twardoch]

On the other hand — STAT does not define bounds, right? So if I'm making a font speculatively, I may want to make a regular that links to a bold that's not there yet. But, well, yeah, I should still define the bounds in the stylespace for that speculation, I guess. So a check is fine.

[madig]

I'm not sure I understand. The multiple-fonts-one-Stylespace use case I had in mind is Source Sans Variable Roman and Italic. You'd use the same Stylespace for both, doesn't matter if in an external file or copied into the lib, and the Stylespace contains the upright and italic entry for the ital axis. That way, statmake can check on load that the linked_values for any axis actually point to something that exists. It's a safety precaution because it enforces internal consistency.

At DaMa, we use one external file to describe the entire family, so that's my focus. Warnings may get ignored because people don't understand the STAT table, but errors force people to at least contact us to find out what's wrong.

I don't want to support all possible use-cases and then maintain them, just the ones that bring the greatest benefit in my estimation.

[twardoch]

Yep, got it. I'm concerned that functionality that was legitimate and worked well doesn't suddenly break. :) But it's your software! (Perhaps an "ignore errors" flag at least?)

I think, "good vs. bad practice" differs between things that are established and things that are new. Part of introducing new things into the world is that, I feel, tools should be a bit permissive or at least have a way to make errors. Otherwise you won't easily be able to test, say, apps with "wrong" data. And today, the STAT support is still experimental. If something is established (like, I don't know, the cmap table), then tools can employ a stricter straitjacket on the user.

But I understand the desire to help font makers in setting boundaries. I myself am often much more at the forefront of implementations, and dealing with problems that can be either in a font, or in a font-consuming app, or in the font-making app (like FontLab), so I tend to like to have a "developer mode" if possible. "Safe boundaries" sometimes create an illusion of safety, cuz bugs may be lurking in untested areas.

Ok, 'nuff said on my end. Thanks for your work on this!

[madig]

STAT support in applications is indeed... fragmented, shall we say.

Don't get me wrong, I'm not opposed to allowing more use-cases, but I want to set boundaries where I can because it's too easy to get STAT stuff wrong and end up with a spaghetti code base that you can't easily maintain. In fact, I already feel the need to refactor the code...

If you need a developer mode, I'd actually like to see fontTools' STAT object kitted out with convenience methods to quickly set arbitrary data via a script. Once boundaries for things are established, statmake could adopt them.

[twardoch]

You're right. I wish it was as easy to deal with name table entries in ft as it is to deal with glyph names. Dealing with nameIDs "on foot" always makes me "errr... nah" before I write some code :)

[twardoch]

In fact, thar statmake deals with names directly is the biggest convenience. Otherwise pure STAT ain't that bad at all.

[madig]

I'm going to implement a strict check for linked values to exist within the same Stylespace. You can use the new fontTools.otlLib.builder.buildStatTable API if you want to insert arbitrary data.