Hi
I am using a brace layer on one axis and two masters (weight) for the letter R
can’t seem to preview it in FontView
thanks
Seb.
Can you send me the .glyphs file please to support (at) (this website without www). I will have a look.
I had a look at the file and there seems to be a problem. I’ll have a look tomorrow.
I sent my own file to support@(site)
Because I encountered a similar issue.
At current stable release, it exported the GX file I sent you (broken on brace layers) so I upgraded to the edge version,1038, added the Axes parameter, and got this error on export:
It is possible that there is an incompatibility introduced during TT conversion. What doe the outlines look like? Do you have an inflecting curve?
As far as I could tell, before I upgraded and could still export the TTF file, it affected every character containing a brace layer, regardless of whether or not it had a curve - /N for example
The font you sent to support@… exported without a problem after I added an Axes parameter to File > Font Info > Font and deactivated the oblique instances in File > Font Info > Instances. I recommend you keep upright and oblique in separate files.
Ok, that fixed it for me too, thank you! Because I am just generating faux obliques for the moment anyway, do I even need italic instances to use the ‘slnt’ axis, or can the browser do all of the work? I am thinking about using it in CSS if possible (i.e. font-variant-settings: ‘slnt’ 7, or something similar)
Hmm, looks like that didn’t fix it, actually. It exports, but it is still broken on glyphs with brace layers (/a/r/b/e/o/n/s – /V/i/l/F/t are fine), i.e. the same behavior as before I upgraded to 1038
I could fix this by dragging the masters in the right order: first the condensed, then the extended masters. Alternatively, use an Axis Position parameter.
@mekkablue Are you sure? When I drag the masters in the right order (assuming you mean like [1]), it is correct only when the weight is at either extreme (thin or black)
Top 4 are fine because weight is extreme, bottom isn’t. Is “Axis Location” for Font Info->Masters? It isn’t helping either. Odd.
Experiment with better placements of the brace layers. Consider 300-500 rather than 3-5 for the width. The Masters > Find and Replace in Layer Names script from my repo can help.
I have tried that with no success. Tried 50 75 100 and then 300 400 500.
The Masters > Find and Replace in Layer Names script from my repo can help.
And deprive myself the joy of typing (“\s*{\s*\d*\s*,)3(\s*}\s*”) ? 
It does not do grep, sorry. 3} for 300} did the trick for me 
I am not sure now, perhaps we need to place brace layers on opposite sides of the design space as well, effectively turning the design space into quadrants, or do the arrangement from scratch, maybe it is something we both overlooked.
I suspected maybe the brace layers at semi-condensed black (i.e., layers that exist outside the masters) were causing the problem, but no.
Do you know of an example variable font with brace layers where this error does not occur? Would be useful to compare
Other thought is that the brace layers are attached to different masters – maybe connecting them all to the same will help.
EDIT: nope, not it
I have sample fonts but single-axis only. This may as well be a bug. What you can try is a setup like this:
The grey dots being the brace layers. Just add them with the correct coordinates, and then reinterpolate (via the gear button in the Layers palette).
1 Like
Yes, I think it is a bug. It seems the problem exists only for glyphs that have a brace layer modifying both the width and the weight, but not the weight alone.
I think I understand your drawing correctly (weight is from 22 to 188, so assume width exists in same range, and correct it?)… I will give it a try
Actually not sure I understand the drawing. If the red dots are meant to be light condensed, bold condensed, light, and bold, then I think I have many brace layers along the grey lines