Solution for non-orthogonally placed instances in a Variable Font

[WeiH]

I am working on a VF right now, it has a weight and width axis with 4 masters and 48 instances and 5 intermediate sparse masters, this is the .designspace:

I've been informed by Adam Twardoch that this is non spec-compliant and it is also returning a lot of errors in fontbakery :) Adam's solution was that I should export all the instances where the designspace breaks and re-set that in the 'correct' place. The problem for such a family is that I think it means adding almost a dozen or so masters. Is this really an okay solution as it just seems like a waste of file size? I am wondering if this is an absolute necessity for VFs for Google Fonts.

[Dave Crossland]

I think Botio had a similar issue recently... Botio, is that right?

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/f5a3bc1d-afa7-4c02-af8d-5cc1eabf075d%40googlegroups.com.

[Adam Twardoch (Lists)]

Botios problem was simpler. 

Wei's design designspace is much more irregular, so I don't think any kind of bending or smart recalc can help. To transform the design designspace to production designspace, at this point, using the instances as intermediate masters seems to be the only solution. 

I've been informed by Adam Twardoch that this is non spec-compliant and it is also returning a lot of errors in fontbakery :)

Well, this is fine as the design designspace. But to get the production designspace suitable for OpenType VF, in this case you indeed need to export these instances and then use them as masters at the spec-compliant wght and wdth locations. 

In the far future, this may be resolved with the avar v2 OT table, but we're nowhere near it yet. 

A.

[Nikolaus Waxweiler]

How strongly required is it that the VF absolutely matches the statics? Doing it this way makes future maintenance a nightmare and probably bloats the file size beyond what people would comfortably want to download...

[WeiH]

I think even if it’s not a static to VF conversion project you’re going to come across this case anytime there’s more than one axis that affects weight, contrast or proportion unless you’re very careful about planning the interpolation space specifically for VF in mind.

[Dave Crossland]

I wonder if David Berlow can explain why parametric axes solve this? :) 

On Mon, Jan 20, 2020, 7:21 AM WeiH <weiand...@gmail.com> wrote:

I think even if it’s not a static to VF conversion project you’re going to come across this case anytime there’s more than one axis that affects weight, contrast or proportion unless you’re very careful about planning the interpolation space specifically for VF in mind.

--
You received this message because you are subscribed to the Google Groups "Google Fonts Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to googlefonts-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/googlefonts-discuss/a8291534-ee28-4109-b0b2-dd4d2ffef34e%40googlegroups.com.

[Thomas Phinney]

I understand that the masters are just the spots marked with + signs, and the rest are just instances, which for purposes of the current discussion are mostly noise. Unless they are looking at instances going beyond the design space defined by the masters—can’t tell if that is for real, or just points on top of masters being displayed slightly offset. Hoping the latter. Assuming so....

1) IF the middle partial master (the green one) can come down just a tad to the next line down, problem solved.

2) Or, the two side masters come up, similarly, for that matter. 

Either way, interpolate and redefine with the new master. The shift is so small that I would be surprised if it were fatal. 

If neither of those is viable, then (3) the designspace requires three more intermediate partial masters, in the positions just mentioned in (1) and (2) above, as positions that masters could move to.

T

[WeiH]

I thought the issue was the placement of the instances rather than the intermediate masters. I assume the issue regarding the orthogonal space remains even without the intermediate masters.

[WeiH]

Stephen Nixon made some notes for this problem:

https://github.com/thundernixon/Encode-Sans/tree/wip/docs/01-morphing-non-rect-designspace