GlyphsApp, Prepolator, & Superpolator vs. Just Plain GlyphsApp

A question for my fellow Glyphs users: if you supplement Glyphs with Prepolator and Superpolator, how come? What do they do for you that Glyphs's own tools can't?

Comments

  • 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#L3

    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?
  • It is true that you can do some things in Glyphs that cannot be stored inside a UFO (or would not make sense to store in a UFO). Most of it is related to interpolation (brace and bracket layers), hinting, and some of the new features like smart glyphs and corner components. You have to keep that in mind if you want to work with other UFO-based apps.

    For things that can be stored in a UFO, however, it is no problem. E.g., a number of users prefer to do their kerning in MetricsMachine, for which you can simply export a UFO and re-import the kerning.

    More on the subject: https://www.glyphsapp.com/tutorials/working-with-ufo
  • I used to work a lot in Prepopolator and Superpolator, but since moving to Glyph I no longer needed Prepopolator or Superpolator. The 3 interpolation axis that Glyphs offer are enough for me at this time.
    Also, I prefer very much the Glyphs file format over UFOs. Just 1 (relatively small) file for all 9 masters, instead of having 9 huge and bloated UFO folders and hundreds of files floating around.
    Other thing that I like very much about Glyphs is the "1 click" OTF generation for all the instances. It's really fast and convenient.
    I'm truly grateful for the UFO format, since it made a lot of things possible. But now a days I find the Glyphs file format to be more convenient, at least for my needs.
  • James PuckettJames Puckett Posts: 1,688
    Superpolator and Prepolator are great tools, but I haven't needed either since switching to Glyphs.
  • Dave CrosslandDave Crossland Posts: 1,052
    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?
    I'm not sure what these are exactly in Work Sans, but Glyphs 2 introduced a bunch of new things (corner components, stem components, 'smart' components) which aren't directly represented in UFO. When you export instances/masters from Glyphs to UFO, these things are 'decomposed', so no longer interchangeable. 

    Of course you can forego such things to use Glyphs 2 as an interchangeable UFO editor, but then you lose all the features that draw people to Glyphs in the first place ;)

    In contrast to my views a few years ago, 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 guess that the native-UFO apps are far too expensive for their market, so they don't have enough volume, so there isn't enough revenue to enable the spec authors to spend time on implementing the UFOv3 format, or developing a v4 that is more than rejigging on the on-disk data format.

    I was surprised to learn that Monotype moved from FontLab to Glyphs instead of RoboFont (eg from photos in https://storify.com/Monotype/fontmarathon) when the other larger foundries with engineering staff (like Adobe) have mostly moved to RoboFont or stayed with FontLab. 

    So I personally see the .glyphs format as already having become established as the new 'industry standard' source format, and I think its likely to soon become a new interchange format too: the file is plain text, the Glyphs developers are making an effort to document it, and they are as willing to accept request/suggestions for improvements as the UFO editors (if not more so.) 
  • What Dave said. With a "sigh" added. 
  • Ps. Pablo — I think UFO as it is today is somewhat "overdone" and overly verbose. Also, I think there should be a way to "pack" and "unpack" all these sources into a more compact form if they are all itemized. Just like you can put all your CSS and JS inline into your HTML, or keep them in separate files and link to them. I see no reason why the same shouldn't be possible for font sources. It's possible for shipping fonts already: you can have your entire font family as one TTC or multiple TTF/OTF files.
  • Adam,
    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 single-file approach bears significant advantages for both version control and online storage/backup systems like Dropbox. Both things are problematic with the UFO folders, at least as soon as you have many .glif files and update all of them at once.
    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.  
    The .glyphs file format is open sourced and documented (being updated for v2), and it is easy to write a third-party tool that processes .glyphs files. What about FLS? :)
  • Rainer,

    thanks for the clarification on the number of masters per axis, that's good news.

    I apologize for me being mis-informed. Was this always "any", even with Glyphs 1, or is this new in Glyphs 2? I thought Glyphs 1 only allowed one intermediate master but it's likely to have been my mistake. I'm still new to Glyphs 2, got a copy just a few days ago. It looks good! (I particularly welcome rectangular sharp nodes :) ).

    I definitely applaud the fact that the spec for the .glyphs format is published.

    We consider our .vfb and .fog formats legacy formats, designed in a different time period, and in such a way that it's difficult to interpret without extensive code. But FontLab published its only XML format we've developed so far (.phf) a long time ago.

    We plan to publish the format of our upcoming tools. The format will definitely be human-readable. We're still debating its details, and discussion such as this are very helpful.
  • Adam TwardochAdam Twardoch Posts: 449
    edited July 2015
    Ps. Rainer, as I wrote to Pablo, the multiple-file problem can be solved through adequate packaging. I think ultimately, people see benefits and disadvantages in both approaches.

    The Adobe FEA file is "by default" a single file, but it has the "include" directive that allows people to be more flexible, share assets etc.

    This is how it works in HTML as well: you can have all assets inlined or split into external structures. I think such a flexible approach would be best. It could combine the benefits of both .glyphs and .ufo.

    This is also how fontTools/TTX already works, you can have one monolithic file or split it by tables, and even externalize the images into separate PNGs. We have done the same in the Photofont .phf format.

    I think forcing the user to pick one or the other, as the only option, is limiting.

    For example, I really think storing hundreds of PNG images inline inside a large monolithic XML file is not beneficial to anyone, really, would you agree?
  • Yes. For binaries like images, we only store the relative path. For any other font data, I am not so sure it makes sense. Issues include data integrity and user-friendliness (think of e-mailing the file, how often will people forget about tracking and including every linked file?), and the advantages I described before. Should be easy for a specific tool to pick out the stuff it needs to take care off and leave the rest alone.

    (Glyphs 1 could always have any number of masters on a single axis setup. With two axes, it was a little more difficult in G1.)
  • Max PhillipsMax Phillips Posts: 463
    I started something.

    Thanks, everyone, for your insights. The small part of it I could understand was really useful.
  • Dave CrosslandDave Crossland Posts: 1,052
    edited July 2015
    I think a default single file with a spilt option is good, for reasons Rainer and Adam both state. I put an issue up for fontTools to spilt the cff and glyf tables further, into per glyph files.

    Adam, I don't see the contradiction. Glyphs format is open like ufo is, except ufo has been frozen by its maintainors.

    Most designers now use glyphs except a few mutant libre software people who demand design tool freedom for themselves and their friends but not the public, and fewer actual libre software people who use fontforge. So, glyphs format is now the industry standard, and all the freetards need to catch up.
  • The World According to Dave
  • Rainer, 

    Thanks a lot for the clarification! 
    A.
  • Dave CrosslandDave Crossland Posts: 1,052
    edited July 2015
    Frank, how many users does that ol' Ikarus suite have now.... more than 10? :P 

    Adam, you wrote, emphasis mine:
    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? 

    I basically agree with you. With discussions about next binary font format underway, I think discussing the next source/interchange font format is needed too. I think FontLab VI's native file format might be a useful contribution to this discussion, but has been vapourware for years.

    Glyphs now has similar functionality to FontLab VI, and it has a published file format representation. There are now 1,000s of fonts, soon to be 10,000s by the end of this year, that use that format. 

    If FontLab VI is not compatible with that format, so that users can not migrate from Glyphs to FontLab, I think FontLab Inc has got a real problem on their hands. And this problem is going to get worse and worse the longer that the FontLab VI file format remains unpublished. 

    Similarly, while (a) you cannot losslessly move a Superpolator project along with its UFO masters into a Glyphs project, just as you cannot losslessly do the reverse, and (b) while Prepolator + Superpolator + Robofont is €925 per seat (if they will even sell it to you ;) and (c) while Glyphs is €250 per seat, then the market trend underway of designers with UFO projects doing the annoying work to translate them into Glyphs, and abandoning UFO workflows, will continue. That is indeed the topic of this thread: What Glyphs can do today meets the needs for all but the most extreme of projects. 

    So I think the question is not about is a format 100% interoperable? but rather about is a format extensible to meet new needs without trashing other data? And I am optimistic that the .glyphs format can be such a format. I have filed https://github.com/schriftgestalt/GlyphsSDK/issues/2 and if Georg agrees to that, I think that the .glyphs format and plist will overtake UFO and XML pretty rapidly.

    Developing a "universal all-encompassing source/interchange format" sounds great, but talk is cheap. Would FontLab be willing to make its VI format public this month? :)

    I think https://www.sqlite.org/appfileformat.html makes a very strong case for sqlite as being a great on-disk format for new applications, and for me that's tip has been one of the great takeaways from the conservative UFOv4 discussions. 
  • Frank, how many users does that ol' Ikarus suite have now.... more than 10? :P
    Yes.

    Sent from my Parallel Universe


  • Rainer, you say:
    A single-file approach bears significant advantages for both version control and online storage/backup systems like Dropbox.
    Please, can you explain how a single file is better for version control. I'd argue the opposite is true.


    Dave you say:
    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 don't see how the Glyphs file format improves the situation substantially, it's not winning over UFO because it being per se a better format for what you describe here.
    Also, to ensure you break nothing when adding custom data into a glyphs file you really should have a defined way for extension.

    For UFO, I'd like to see the adoption of real XML-tools like XML-Namespaces and XSD and opening the format up for non standard extensions more easily. So that people are not forced into doing nonstandard or sub-optimal things. Also, that plist-xml format could be replaced by something less verbose.

    A future format must be able to cope with non-standard data from all kinds of tools, even those that we can't imagine now. 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.

    SQLite could be used as a underlying structure, but I doubt that it would find much appreciation because people would have to learn SQL. As much as real XML tools within UFO is not happening, which is a pity.


  • > The core of the format would be a mechanism for extensibility, with just enough rules to achieve a common order of things.

    Yes! :)
  • Wei HuangWei Huang Posts: 93
    edited July 2015
    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#L3
    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?

    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

  • Dave CrosslandDave Crossland Posts: 1,052
    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?

    As for smart, cap and corner components—I don't know yet how that could be made into a .UFO compatible workflow

    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? :)

  • Wei, 

    Superpolator 3 has had the functionality called Rules for quite some time now: http://new.superpolator.com/documentation/rules/ — does this sound familiar? :) 

    A.
Sign In or Register to comment.