generating Style names

[schriftgestalt]

I see you put a lot logic in the instance generator to automatically generate proper style names. (Put width in style name instead of family name #35). I don't think that is the right place to do this. The style names should be properly set in the .glyphs files already.

There are three ways to do that.

1. Do it manually in Glyphs.app. That might be difficult to get right as many people working on this files and not all of them might get it right.
2. Provide a script to run in Glyphs.app that sets the names correctly. That has the advantage that people testing from within Glyphs.app will get the same result as if generated from fontmaker.
3. Use a preprocessing script that adds the information to the instances but is independent of the actual interpolation code.

That has at least two advantages.

1. It simplifies the export script
2. The library would be more flexible and could be used to produce fonts with different requirements on style names.

So I think the export script should stick to whats in the .glyphs file and not trying to fix things.

[twardoch]

I think these goals aren’t mutually exclusive. Style name generation based on some parameters and otger such production-related routines that allow to enhance or customize the input data are useful — regardless of the input data format. If .designspace + set of .ufos is the intermediate format on which certain routines can be run, even better. This set-up of files can be generated from .glyphs, but also from .sfd or some FontLab formats.

But I agree with Georg that putting elaborate logic into Glyphs-specific reading routines is probably not ideal, and these operations might ultimately be offloaded into a somewhat more format-independent layer.

BTW, I think .designspace has potential for extension. Currently, it's a rather "lightweight" file but ultimately it could gain a bit more capabilities and act as a "project management" file of sorts.

[schriftgestalt]

That has nothing to do with the input format. This library is useful for generating instances from a specific master format. The main use case for now is to produce the Noto fonts. But to put the specific requirements for Noto in the instance generator is making it harder to use it for other things. That is as if the code would correct some design issues on the fly. Maybe another project depends on those unusual configurations.

All other formats (.sfd or Fontlabs) have the capability to store all needed info. So the same applies there as well: Define all needed info in the source file.

[twardoch]

Yes, I agree with that. We obviously agree that the Google guys have a business rationale of writing this wonderful software — and that is, primarily, to build a production system for the Noto fonts. But I think we all also agree that if a library such as glyphs2ufo is to receive bug reports or gain more functionality, then certain behaviors that can be made modular or optional should be made so.

However, I also know that often, writing something that "just works for my project now" is also valuable simply because you get your job done.

So, Georg, I agree with your sentiment. I hope that the developers here will ultimately find time to move this kind of "smart logic" into an optional nodule, so that users of the glyphs2ufo package can use it to "passthrough" data (relying on the input data being "right"), or to "enhance" or modify stuff.

Judging from the progress of the project, I think everyone here agrees that this should ultimately happen. And I think, as long as we agree on this, we also accept that "for some time" (until the next refactoring ;) ), some Noto-specific stuff can get hardcoded. But then it should be moved out. :)

[behdad]

We definitely don't intend to encode Noto-specific logic in this module. I think what happened is that the sources we received from our vendors had bogus and inconsistent naming data, so James ended up ignoring them. But we all agree that we want to reverse that decision, retain names and remove heuristics, and fix the naming issues in the source.

I'm personally so far away from the details here, so I let Georg and James work it out together. Thanks.

[behdad]

Or, quite possibly, I don't understand what's exactly the issue is :).

[twardoch]

Well, I sort of do: the design sources often contain “incomplete” instance info. In case of Noto, Monotype delivers the sources but it’s really up to Google to “productize” it into final fonts. This is actually quite common with foundries. External designers may not always have the full knowledge about how the foundry (in this case Google) wants to finally release the fonts — with which naming, which copyright entries, and which instances setup.

I generally think that control over “what font files do we want to generate, with what naming and which design space positions, with what outline flavors etc.” ideally belongs to some external “instance files” that describe the “target formats”. This info could be included in an extended form of .designspace or on some other form of “make targets”.

So, the situation that Behdad describes (“the sources we received from our vendors had bogus and inconsistent naming data, so James ended up ignoring them”) is actually very typical in the font world. In a way, “design” and “productizing” is often controlled by different entities, sometimes with even different goals (the “productizing” part is often controlled at least in part by the marketing departments of the final font foundries, with input from legal and technology).

A good font production system should allow to define “design sources” and “make targets” separately. When you editing one, you shouldn’t necessarily be able to screw up the other, and they should be physically separate so they can be maintained by different people, often within different organizations.

[schriftgestalt]

I think in most cases, design sources and production sources should be in sync regarding instance settings (design space and names). That is especially so with OpenSource software when someone tries to generate instances on their own from the original design sources (the .glyphs files in this case).

[twardoch]

I agree. That used to be true for most simple scenarios, where you just need a 1:1 relationship between sources and targets. But more and more, this is no longer the case. You often want a CFF-based desktop family, TT-based desktop family, some webfonts, and potentially some other formats. Also, people often make customized versions for clients — from the same sources.

In general software development, you often have one set of sources (say C or C++ files) but you want multiple deployment targets (for Linux, Mac, Windows etc.). This is increasingly no different with fonts.

It is true that most individual type designers who want just one set of fonts, and they make them themselves using an integrated type design app like Glyphs, FontLab VI or RoboFont, there should be a way to store “default” production settings for one format. This is how FontLab Studio 5 used to do it, but we’ve found over the years and this becomes an obstacle for the more heavy-duty users.

The prevailing reality is that more and more type design projects have an “n:m” relationship between sources and targets (usually “1:m”). I agree that it’s good to have “good defaults” stored in the source, for the most common output format. But this does not contradict an effort to try developing an easier solution to handle the “n:m” relationships.

[jamesgk]

First, I'll echo the sentiment that we definitely don't want this to be Noto-specific. It's just that those are largely the only sources I've been testing with. Testing with other sources we don't immediately need to handle is a goal, but I haven't gotten around to it.

Another problem is that the dependencies for generating UFOs (defcon and mutatormath) are fairly complex and do a lot of name handling themselves, and I don't fully understand how they work. We can try to whittle down the code in this library while testing to make sure output is still reasonable. But that also takes time.

I'll also clarify that when just reading data from the Glyphs file, we don't do anything tricky. It's only when writing that data to UFO that we move a lot of stuff around.

[jamesgk]

My goal for this library is basically to 1) match Glyphs itself wherever possible both for naming masters and instances, but also 2) to make sure that output will conform to UFO/OpenType specs (for example, only include one of four possible permutations of Regular/Bold + Italic/NonItalic in name table entry 2).

[belluzj]

Is this still relevant? In the current master:

1. the styleName is generated only if the Glyphs master doesn't have a name: https://github.com/googlei18n/glyphsLib/blob/0a86327a93b3f324f200e35a23f639db4ae58280/Lib/glyphsLib/builder/names.py#L37
2. the styleMapFamilyName/styleMapStyleName are only generated when building the font with fontmake, not when round-tripping to UFOs and then back to Glyphs: https://github.com/googlei18n/glyphsLib/blob/0a86327a93b3f324f200e35a23f639db4ae58280/Lib/glyphsLib/builder/names.py#L46-L51

Is that satisfactory?

[anthrotype]

the styleName is generated only if the Glyphs master doesn't have a name

when does it not have one?

the styleMapFamilyName/styleMapStyleName are only generated when building the font with fontmake

Is that when we build UFO masters (as masters in Glyphs.app can't have those custom parameters)? I'm ok if we move that over to ufo2ft.

[belluzj]

when does it not have one?

Good question :) I momentarily don't have access to Glyphs to test that, but it sounds stupid anyway to have a master with a blank name. Maybe in tests, when we build near-empty fonts to just test one small thing?

Is that when we build UFO masters (as masters in Glyphs.app can't have those custom parameters)?

Yes (however I'm slowly realizing that when I use glyphsLib to go from UFOs to Glyphs, I put all the UFO stuff into the GSFontMasters, so I'm probably storing the styleMapStyleNames there even though those customParameters will show up in grey because Glyphs does not "allow" them on masters)

[anthrotype]

will show up in grey because Glyphs does not "allow" them on masters

well, if Glyphs just ignores them, they don't do much harm.

I'm thinking that maybe fontmake should actually stop allowing to build non-instance master UFOs or TTFs from a glyphs source file, as an output format. Meaning, fontmake -g MyFont.glyphs -o ufo,ttf should always make instances (whichever they are in the glyphs source), never masters as standalone fonts. In other words, the -i option (for --interpolate and apply_instance_data for instance custom parameters) should always be implied when starting the pipeline from a Glyphs input. Glyphs.app itself doesn't allow to export the individual masters of a GSFont as independent UFOs, and thus TTFs, does it? It always requires an instance, even for simple fonts that only have one design master.

We could add an extra -o designspace output format (only valid for -g input) if one only wishes to create a designspace+master_ufo/ from a .glyphs source, but without also interpolating the instances. Yeah, probably for a different issue tracker.

[schriftgestalt]

The ‘exporting’ of ufos actually writes the masters and maybe should also write a designspace file.

Exporting to TrueType is a totally different thing and indeed will require an instance (if the file doesn’t have one, it will make a temporary one during the export).

[anthrotype]

Ok yes, I meant that generating UFO masters from a Glyphs source file without the accompanying designspace that glues them together (though we duplicate the shared font wide data in each masters) and that contains the extra data belonging to the instances (that are meant to map 1-1 with exported binary fonts) is incomplete, and should probably discouraged.