Is that a reason to prevent export a variable font? I don’t think my outlines are too problematic, but maybe you can tell me what’s going on.
Variable fonts contain TrueType curve. The conversion if segments with inflections are difficult. Can you show the outlines of the “W”?
If the ShowAngledHandles plug-in gives you many laser beams, that would be an indicator.
I could imagine so. It does have those. Thank you, I could tweak the curves to make it work. It’s a very fluent design with rather crazy beziers. But nothing is impossible 
I also got this error while attempting to export NotoSans-MM.glyphs into a variable font.
Glyph “uni2C73” (and possibly more) is affected by this error message.
I don’t remember if this ever worked in the past. I wonder, has the quadratic conversion algorithm changed in some recent Glyphs.app version?
FWIW, the cu2qu algorithm doesn’t have problems converting curves with inflections
Maybe some Glyphs.app filter that converts curves compatibly using cu2qu could be nice to have.
1 Like
To have more than one inflection is almost always an error. And in the Noto file it most certainly is. There is a path with overlapping handles. Of course, this particular path could be converted to TrueType, but others probably not.
Edit: I relaxed the error a bit. So the outlines of the NonoSans are exporting now. The outlines need some cleanup (The ink trapes are quite bumpy, and the outline in the first master is shifted down by one unit.)
I didn’t want to start a new topic, as I knew this question has been asked several times and in several forms over the years, but I have tried everything I can think of to figure out why I can’t export my variable font, and continue to get the “too many inflections” error. For background, it has two axes, weight and slant, and 5 masters (each of the 4 extremes, plus one “canonical” regular weight/slant combo). I don’t think this should matter, but it is for the Old Nubian script, which is a slanted uncial style largely based on Coptic/Greek. All 5 masters are compatible (verified through the compatibility checker) and I have:
- Run the ShowAngledHandles plugin to fix ‘laser beams’ (I don’t understand why they are called that, but my understanding is this is related to the brightly highlighted segments, not the red handles, right?). I also ensured that all of the overlapping handles (Xs on the handles) errors were removed.
- Run the “Insert Inflections” filter to ensure I wasn’t missing any inflections
- Used the Red arrow plugin to identify any other inflections that I might have missed, and added those - (Although I did leave some ‘yellow arrow’ warnings where there was a subtle inflection which didn’t occur in all masters, as it seemed against “best practice” to add a node which would in some masters be completely redundant.
I still can’t export or run the HTML Variable font test (with OTVar?), and I can’t figure out why, so any insights would be appreciated!
1 Like
Do you use outside self inflections in your design? I just had the same complaint by another user and improved the error message a lot that it is easier to find the problem.
sorry - I am struggling to visualise what you mean. Can you give an example of an outside self-inflection?
no none of those afaik
Can you send me the file for testing?
I have sent it to you - thanks!
You have those self inflections, albeit unintentional. e.g. in the gamma-coptic. It is not an obvious outside inflection but as your path direction is wrong, it is treated as one.
And there is a quite unusual path setting in the vida-nubian2 (and again a wrong paths direction):
Thanks - as you can tell I didn’t realise that external self-inflection was there - what is it that makes it the wrong path direction? I will look for others with that issue and hope that will resolve it!
‘vida-nubian2’ was an alternate, but is no longer in the character set, I should have deleted it
Thanks!
In type design, paths should be counter clock wise. Have you read this: https://glyphsapp.com/learn/drawing-good-paths
1 Like
Thanks - I had seen that tutorial, but I obviously missed that important rule! 
Can you clarify what “This does not apply to variable fonts” is referring to? Is it activating the “remove overlap” option
(also I have successfully exported it as variable font and been able to demo it on Axis Praxis, etc - many thanks!)
That execution rule mean that variable fonts have explicit support for overlaps. Because a lot interpolations wouldn’t be possible, otherwise.