Hi folks, I am searching for help…
I am working on a project which has inconsistent designspace coordinates.
For example:
Regular, weight=20, width=90
Bold, weight=50, width=100
Condensed, weight=22, width=43
Bold Condensed, weight=54, width=47
If it was only static files expected, why not… But for a functional VF… is it possible to export a proper avar and stat tables? Are these kind of coordinates okay? Maybe I see a problem where there is not.
I encountered the same issue. Have you already found a good solution to create an avar table Rosalie?
The only solution I found was to make the designspace consistent again with One coordinate matching one user value… I created masters from instances etc but there are few inevitable regressions.
Yeah masters from instances sounds like the only solution. Thanks anyways! 
Eight move the masters a bit to give a rectangular shape, or add more masters (from instances). In the later case you probably what to remove some of the original masters to reduce complexity.
Hi, I ran into the same problem. We are producing Variable Fonts of existing families and are expanding character sets. We want to produce new static (intermediate) weights from the new Variable Sources. Of course the new static fonts should be identical to the pre-defined instances in the Variable Fonts. Currently one can only have the same value for the condensed weights as for the normal weights. Our family started off with 5 weights Light–Black and 5 weights Light Condensed–Black Condensed. Thin and Thin Condensed were added at a later date. The easiest and fastest solution keep the new static fonts in sync with the existing family was to create individual instances (with values set at the stem widths of the existing weights) for the Light and the Light Condensed and create intermediate Masters from these. Everything works fine now, but we still have some minor differences in the Medium and Bold instances.
IMHO it should be possible to solve the problem in a more elegant way. Instead of the Condensed instances being dependent from the Weight values of the normal widths, I think it should be (made) possible to replace the fixed weight for let’s say the Light weight by a weight for the Light weight and the Light Condensed weight and insert a formula which calculates the Weight of the intermediate Width (between Light and Light Condensed).
I do not see the point of a ‘user experience’ which would need ‘the same weight’ when opting for a weight value of 600 for example. After all, this value is as unprecise as ‘medium’ and in decently designed families, the stems of the condensed weights are designed thinner than their corresponding normal weights. If one would not do so (and keep the stem widths identical), the condensed weights would appear darker than their accompanying normal weights. To get an impression of what this means one can compare the old weights of Univers according to the famous scheme Frutiger once created (the one with the numbers) and compare it with later releases such as Univers Next.
Edit: I do understand that the current mechanism allows for Condensed weights being thinner that normal widths, but I think that my proposal would allow for:
– more precise backwards compatibility with pre-Variable versions of typefaces (important for continuity and consistency in Corporate Design projects)
– more sophisticated adjustment between weights in larger type families.
To me the question is:
Does the Variable Font Spec allow for calculating instances from two different Weight values for let’s say a Light and a Light Condensed weight, rather than calculating such an instance from one Weight value for both weights? If so, can this be implemented?
You can’t have “diagonal” interpolation (as you can in Glyphs with static instances).
Sorry to hear that! But is this a current limitation of Glyphs or is this a limitation of the OpenType spec?
This is a limitation of variable fonts.
So sad …