Horizontal metrics change between weights in source

[laerm0]

The variable version of Open Sans was created with equal metrics between weights. This is ideal so there is no reflow as the user/designer changes sizes. However, this will certainly cause reflow all over the internet if designers switch from the static weights to the variable fonts on their pages. As @m4rc1e puts it, this will break the internet.

I am of the mindset that we should move forward with this, but it would take a sustained PR campaign for designers to become aware of this and decide if they want to go to the VF or stay static (good luck to @davelab6), so I also think that Open Sans VF should be served as a different family so this doesn't happen.

As this is the first substantial remastering of a static family for VF that we are preparing to release, I feel like we should set a precedent and try to stick to it. Should we serve VF fonts alongside their static versions, or should we essentially overwrite static fonts with their variable versions?

I can see a plan where we have a Google Variable Fonts – with variable fonts being the focus and static fonts being deprecated – but this certainly entails a substantial reworking of...uhh, everything associated with this project.

Anyone who has opinions, please share them.

[laerm0]

The italic has this same thing, of course.

[davelab6]

The variable version of Open Sans was created with equal metrics between weights. This is ideal so there is no reflow as the user/designer changes sizes.

In my opinion, this is a "Grade" axis, not a "Weight" axis.

The brief for all the VF projects this year has been to make VFs that can replace the previous static fonts, essentially reducing the scope of Variations technology to a compression technique. The "named instances" of the VF should be 1:1 matches for the static fonts.

However, this will certainly cause reflow all over the internet if designers switch from the static weights to the variable fonts on their pages. As @m4rc1e puts it, this will break the internet. I am of the mindset that we should move forward with this, but it would take a sustained PR campaign for designers to become aware of this and decide if they want to go to the VF or stay static (good luck to @davelab6), so I also think that Open Sans VF should be served as a different family so this doesn't happen.

Indeed, we can't release it as it is. It is possible that in the future we could add the current "Grade" axis, but that's out of scope for 2018.

As this is the first substantial remastering of a static family for VF that we are preparing to release, I feel like we should set a precedent and try to stick to it.

The first was Comfortaa (https://github.com/google/fonts/pull/1775) and that is currently not yet published in the main Fonts API but is being staged for it.

Should we serve VF fonts alongside their static versions, or should we essentially overwrite static fonts with their variable versions?

We are going to do the latter; push new versions of font families that are variable and that match the previous release 1:1; that's why Marc has been developing font comparison tools.

I can see a plan where we have a Google Variable Fonts – with variable fonts being the focus and static fonts being deprecated – but this certainly entails a substantial reworking of...uhh, everything associated with this project.

The GF team is still working on how to serve full variable fonts, but they will not be a separate project, and since the majority of families in GF are single static designs, those will remain current for a long time, I expect :)

[rsheeter]

Being forced to publish the VF version as a standalone family is not the precedent we want to set here. It might prove unavoidable but I want to push fairly hard to see if we can make VFs that can replace existing static families. Bytes saved is the top anticipated impact. A VF we can swap in seamlessly will save a lot more of those bytes than a new family. Further, a new family splits the cache and high cache hit rate is a goal for the overall project.

IIUC Open Sans VF doesn't meet these needs today. It isn't clear to me that this means it can't, just that it doesn't right now. Is that right or are there reasons it can't ever be manufactured to replace the existing family?

[laerm0]

@rsheeter I am pretty confident that we can replace Open Sans with a VF version. The horizontal metrics issue is solvable. I will be working with the team tomorrow to come up with a solution.

[m4rc1e]

Related to #15. Felt it was worth opening another issue because it isn't just the horizontal metrics. Imo, this work needs a full design review.