It looks like you're new here. Sign in or register to get started.
I am not offering UFOs since the UFOs generated from Glyphs 2 will not interpolate properly due to using Glyphs 2 only features.
Seems like some Glyphs features aren't compatible if you need to provide UFO files that can be treated as (or interchangeable with) the original source?
Glyphs supports 3 font-wide axes with a max. of 3 masters per axis, so you cannot have a family with hand-edited 4 masters.
3 axes is correct, but you can have many more masters in the design space. Of course, you can have a family with ‘hand-edited’ (as opposed to what?) four masters in Glyphs. You can have any number of masters on a single axis in Glyphs.
A "format" by itself is really worth nothing. Even if it's "XML". InDesign's .idml is XML and Apple Keynote's .key are or were both XML. Doesn't help much if you don't own InDesign or Keynote.
So you cannot losslessly move a Superpolator project along with its UFO masters into a Glyphs project, just as you cannot losslessly do the reverse....FontLab previewed the smartly connecting serifs that will be part of FontLab VI two years ago, and Glyphs 2.1 now has a similar functionality — but are they/will they be 100% identical?
Frank, how many users does that ol' Ikarus suite have now.... more than 10? :P
A single-file approach bears significant
advantages for both version control and online storage/backup systems
I think that today the UFO format is not really working out as a
source or interchange format, due to the spec not storing enough data
that people need to work with, and everyone doing their own non-standard
things in the private storage areas (or even going off-spec in public
areas, as Adobe Type team has done.)
I'm not a Glyphs user, but I did notice this note in Wei Huang's Work Sans repo: I am not offering UFOs since the UFOs generated from Glyphs 2 will not interpolate properly due to using Glyphs 2 only features.https://github.com/weiweihuanghuang/Work-Sans/blob/76764c33e5feb358d98349c3b029086c622ab618/sources/BUILD.txt#L3Seems like some Glyphs features aren't compatible if you need to provide UFO files that can be treated as (or interchangeable with) the original source?
In Work Sans specifically they are intermediate glyphs between Masters for interpolation and alternate Master glyph pairs. To export into a compatible .UFO source for Work Sans currently I'd probably have to create 3 full masters and a few mini-masters containing only those glyphs and then probably a Superpolator file tying it all together.
As for smart, cap and corner components—I don't know yet how that could be made into a .UFO compatible workflow
Thus I agree much with Adams "itemized interchange formats". A container-format that organizes different "tables"/"items". The core of the format would be a mechanism for extensibility, with just enough rules to achieve a common order of things.
Isn't SFNT/TTX already such a format?
If Glyphs 'decomposes' them, it would have to do so in a way that ensures the final outlines are interpolatable.
Glyphs maybe could also export the cap and corner components as regular components placed in such a way that any 'removeOverlap()' function would produce the same result. I'm not sure about this as I think there's something funny going on to smooth the joins, but I didn't check that closely.
I don't think the smart components could be represented in a mutatorMath designSpace.
Rainer, how many users does Glyphs have now - more than 10,000?