Exporting Variable fonts with Glyphs 2.6.5 and/or Glyphs 3.0.3 (3091) is still resulting in massive shifts of composites on Mac OS HighSierra, in Safari and in TextEdit/Pages/Keynote.
This does not happen with Variable Fonts produced in two competing softwares.
How close are we to the BETA flag being removed in the VF export?
Am can you try in a more recent version of macOS or in FontGoggles?
The shifting was a bug in MacOS. Can you send me an example font that works fine in your tests?
Hi Georg thanks for your fast response.
I know that newer versions of Mac OS don’t have this problem.
I also tried to find the thread where the fix is discussed, but I could not find it.
(something about adding an origin point to the composites)
I can email you a font, where the UFO’s have been made in RF and the font was created with fontmake + .designspace and one that is directly exported out of FL7.
Both are not final, but both work fine on High Sierra.
The thing is: the designer of the font above, likes the variable font to work well in as many environment as possible. But since he designed in Glyphs and uses a lot of the automatisation, it would be safest to produce these fonts in Glyphs as well.
Thanks for the file. My hunch was correct. Both fonts use an MVAR table to add variations to the LSB (don’t ask me why that is stored in the fonts in the first place). I have argued in the OpenType lists a few time that adding a MVAR table is just a waste of space. There are so many occurrences where the composites will still shift, specially if you have an italic axis. And as it is not needed in all modern OSs. (the “bad” macOS versions have a market share of less then 2%)
I’ll have a look.
What about adding an custom value to add the MVAR table?
(like you offered with Write Kern Table)
I could name you a hand full of people on top of my head, still using High Sierra, some of them even are designers.
MVAR table to add variations to the LSB (don’t ask me why that is stored in the fonts in the first place)
Sounds actually like the workaround to fix this MacOS issue.
In a perfect world, we as font developers would not have to fix this on the font side. But if there is a fix, it’s neat to not throw those users under the 
For fonts with MVAR, fontbakery reports an “unwanted table”:
The following unwanted font tables were found: Table: MVAR Reason: Produces a bug in DirectWrite which causes 1492477 - Variable Font linespacing differs when compared to their static equivalents on Windows version, Quicksand font: letters cropped in <select> · Issue #2085 · google/fonts · GitHub
Ok, under the 
thou shall be thrown.
Thanks Jens. 
But I’m still a bit puzzled here.
Fontmake (a Google tool) writes the MVAR table, that gets reported as an error by FontBackery (another Google tool) 
:dizzy:
