[varLib] varLib.models.VariationModel assumes all locations are full-range

VariationModel seems to be based on the idea that all “master” locations apply across the full range of the axes:

	def _computeMasterSupports(self, axisPoints):
		...
		# Compute min/max across each axis, use it as total range.

but it suggests that one day this will change and it will be possible to specify location that only apply to certain areas of the design space:

		# TODO Take this as input from outside?

It would be helpful, particularly in the case of variable layout, if locations were able to specify their box min/max points explicitly.

This would require some upheaval - a new interface design for VariationModel.__init__(locations) at least.

[behdad]

Have a look at this single-axis model with 5 masters total:

from fontTools.varLib.models import VariationModel

locations = [
    dict(),
    dict(wght=0.25),
    dict(wght=0.5),
    dict(wght=0.75),
    dict(wght=1),
]
model = VariationModel(locations)
for s in model.supports:
    print(s)

The regions (supports) it calculates are these:

{}
{'wght': (0, 0.25, 1)}
{'wght': (0.25, 0.5, 1)}
{'wght': (0.5, 0.75, 1)}
{'wght': (0.75, 1, 1)}

However, it would be much better (for reasons I tried to describe in #2207 (comment) ) if the regions were these instead:

{}
{'wght': (0, 0.25, 0.5)}
{'wght': (0.25, 0.5, 0.75)}
{'wght': (0.5, 0.75, 1)}
{'wght': (0.75, 1, 1)}

VarLib used to do what you suggest. I changed it after Erik pointed out issues with my implementation:

https://www.youtube.com/watch?v=3RRoIYeJ3YQ

The immediate reason it turned into what we have now is that it was easier (but not necessary) to fix the code to do what Erik expected (and I agree with) by just making it behave at it does currently. So, that we can improve on. Here’s the commit, with extensive commit log: https://github.com/fonttools/fonttools/commit/42bef176a33dc7321eb70f5d49c90317e59ad0e5

However, there’s a legitimate reason for why the current output might be desirable: it produces smaller (and many more 0) deltas, which saves bytes. In a common example where eg. Regular and Black masters are designed, then Bold interpolated and imported as a new master and slightly modified, in the scheme that you propose, Bold datas will all be encoded separately. Whereas if the support for Black master reaches all the way to Regular as current code does, then the Bold master will only encode any data for actual manual modifications that were made to it, and nothing for just the interpolated-then-imported-unmodified parts.

Obviously there’s a filesize vs runtime tradeoff. Ideally we should be finding the sweet-spot of that tradeoff given the actual master configuration. But I don’t have good ideas about how to do that currently. I’m still thinking about it.

And yes, the error accounting is sloppy and errors add up. It could be done better, to account of accumulated rounding errors from previous deltas when computing deltas for each master. That way, the total error for any interpolation point will still be limited to 0.5.

[simoncozens]

Again, I still don’t understand what you are starting from that has regions.

OK, I’m convinced. The tooling can easily make sharp cornered regions by adding or subtracting epsilon from the previous master location. I have enough to do what I want in terms of variable layout.