GlyphsApp, Prepolator, & Superpolator vs. Just Plain GlyphsApp
Max Phillips
Posts: 474
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?
1
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?0 -
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-ufo0 -
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.
1 -
Superpolator and Prepolator are great tools, but I haven't needed either since switching to Glyphs.2
-
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.)4 -
What Dave said. With a "sigh" added.0
-
Dave,
I see a certain contradiction in what you're saying: you say that .glyphs is becoming an "industry-standard source format" while you cite examples of foundries using various tools, and you mention various features of the Glyphs app which are specific to that app.
I see the .glyphs format as a great source format for sources that are created with the Glyphs app. But there are, and will be, more tools that people are using, and I think many of these apps will have some functionalities unique to those apps.
I think there is a difference between a tool-specific source format, an interchange format, and a "universal" source storage format.
As long as you have a tool-specific format, the format typically supports the things that the tool supports, and vice versa. .vfb is a FontLab tool-specific format, .glyphs is a Glyphs-specific format etc. Even between these two, each supports features that the other doesn't. And, there's UFO.
For example, FontLab Studio 5 (and the .vfb format) can store and edit both cubic and quadratic outlines, same goes for UFO.
AFAIK, Glyphs currently only supports cubic outlines, but it does support color bitmaps which old FLS5 doesn't.
FLS5 supports 4 interpolation axes with max. 2 masters per axis, 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. And it has additional glyph-specific axes. Superpolator is much more flexible in this respect.
Glyphs operates on the concept that all masters in a family have an identical set of OpenType Layout features, so defining a separate "cpsp" feature for Light and Black is hard.
UFO stores the features separately per master.
So you cannot loslessly move a Superpolator project along with its UFO masters into a Glyphs project, just as you cannot losslessly do the reverse.
If you have a set of TTH-hinted quadratic UFO masters, if you move them to Glyphs, they will be converted to cubics and that hinting will be lost, and once you generate TTFs out of Glyphs, you'll get different quadratics and different hinting (not better, not worse, just different).
Every tool uses different cubic <-> quadratic conversion math. So even if several tools used the current .glyphs format as its source format for cubics, the final TTFs will differ depending on how you build these.
Sure, some functionalities can map to each other between apps.
But will the results be identical? For example, 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?
For "simple things", they will be. But, as you say, if you want to be 100% interoperable, you'll need to limit the features you use to a lowest common denominator. If you use any RoboFont-specific extensions or any Glyphs 2-specific features or in future any FontLab VI-specific features, you'll lose routrippability.
If you try to create a "universal source format", this may actually hinder innovation. Imagine FontLab had made .vfb into a human-readable, well-specified XML-based .vfx format 7 years ago, and that format was coined "the universal source format".
What would then happen to many of those features that Georg had implemented for Glyphs (e.g. 3 masters per axis or those bracket/brace layers etc.) if there "wasn't any place for them" in the "universal source format"?
I start to think that perhaps, across tool makers, we shouldn't try to develop a "universal source format", or even a "universal all-encompassing interchange format".
Instead, we should perhaps focus on developing itemized interchange formats for various aspects of type making: cubic monochrome glyph, quadratic monochrome glyph, SVG glyph, kerning, groups, glyph set, anchors, glyph metadata, itemized font metadata, hinting, masters and interpolation rules, etc.
These could follow a similar general syntax if needed, or perhaps several subsyntaxes.
Kind of like Apple's AAT tables: each one dedicated to a single task. I like how Apple has size-specific font tracking info a small nifty "trak" table that can exist completely independently of everything else. It's not buried deep inside some monolithic beast (be it XML or binary or TXT).
Look at kerning: the best interchange format for kerning, in a way, is still... AFM! Well, AFM has a few more things in it, but the kerning section could be spun off as ".kpx" or something like that. Cubic monochrome glyph geometry could have its own format, while the quadratic one could have another (similar but not identical).
Itemization is important. I like the aspect of UFO that you have one glyph per file (GLIF), because that instantly gives you not only a file format for a single glyph (that you can send to a colleague in an e-mail attachment) but also a clipboard exchange format, great for copy-paste.
I think the great success of the web is that it consists of itemized formats. You have HTML, CSS, JS, SVG, PNG, and many more. Want an SVG with a fallback PNG? No problem. Want video in two formats? No problem. With Web Components, they now also want to itemize the HTML (which is long overdue).
One long XML á la .glyphs is similar to one long XML á la .ttx. Not good, really. I'd much rather have a source format where I actually have a "binary-in-XML" format á la .ttx, but itemized well, in a tree, with "links" to "better sources" as a "backup" (for example .glif or .fea). So I can store my OTL features as .GSUB.ttx and .GPOS.ttx but they somehow point to a .fea or .vtp file.
A metadata file keeps track which one is more current, and if I update the .fea and run "make", the .ttx files get rebuilt (using a fea2ttx tool which is independent of RoboFont, FobtLab, Glyphs etc.).
I think the only feasible way for type designers to attain an independence of their sources (and their work) is when they have a chance to use alternative tools for each and every one of those "pieces".
Like with the web: you can use some tools to generate your CSS and completely different tools to make your HTML and yet separate ones for your PNGs. And in the end, the browsers "put these all together". Even if one of the elements of the puzzle dies off, you only lose a few % of your work — not all.
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.
Best,
Adam7 -
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.0
-
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.
0 -
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? 1 -
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.0 -
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?0 -
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.)0 -
I started something.
Thanks, everyone, for your insights. The small part of it I could understand was really useful.
3 -
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.0 -
The World According to Dave4
-
Rainer,
Thanks a lot for the clarification!
A.0 -
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.0 -
Frank, how many users does that ol' Ikarus suite have now.... more than 10? :P
Yes.
Sent from my Parallel Universe
2 -
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 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.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.)
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.
0 -
> The core of the format would be a mechanism for extensibility, with just enough rules to achieve a common order of things.
Yes!
0 -
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
0 -
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?
0 -
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.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 802 Font Technology
- 1K Technique and Theory
- 618 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 483 Typography
- 301 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports