googlefonts / fontmake

Compile fonts from sources (UFO, Glyphs) to binary (OpenType, TrueType).
Apache License 2.0
763 stars 93 forks source link

ttfinterpolatable: option to ignore errors #159

Open cjdunn opened 7 years ago

cjdunn commented 7 years ago

would be great to have an option to ignore errors when glyphs are incompatible and keep generating only the compatible glyphs.

Related to generating var fonts using var lib as referenced here: https://github.com/fonttools/fonttools/issues/692#issuecomment-253220046

jamesgk commented 7 years ago

We could potentially drop incompatible kerning as well as glyphs.

behdad commented 7 years ago

We could potentially drop incompatible kerning as well as glyphs.

I'm getting there re merging those.

thundernixon commented 5 years ago

I've made a (slightly messy) RoboFont script to get partway to this idea: https://github.com/thundernixon/varfont-prep

It copies sources described in a designspace file, and from those copies, removes any glyphs that fail the FontParts isCompatible() check. As CJ said in the fonttools thread he links to above, it is extremely useful to generate fonts – even if there are errors or missing glyphs – during the design and early development process.

However, in a recent conversation, someone suggested that this would be a nice option to have within FontMake (their name for the option was --skip-incompatible), instead of in a separate prep tool. I totally agree that it would be nicer for users to have within FontMake.

So, I have two questions:

  1. Is this something that would be welcome within FontMake, or are there any reasons it might be rejected if PRed? I could also simply work to improve the varfont-prep script, but this is less easily findable for FontMake users.

  2. (I'm not saying I can PR this in the near future, but) if I or someone else were to PR this enhancement, where might I/they start? My basic thought is, one could call cu2qu on input fonts, then take any errors reported from cu2qu's incompatible glyphs error, and use that list to remove incompatible glyphs from the temporary UFO files that I think FontMake uses to generate the final VF from. Then, the rest of the generation process would happen on the edited temp UFOs. This is all still quite vague to me, however, so any suggestions around how this might be approached would be really helpful. Thanks for any thoughts on this!

madig commented 5 years ago

(You can sort of have this already, by manually "not exporting" things. Put stuff you don't want into the designspace lib "public.skipExportGlyphs" array. This is done for you if you use the export checkbox in Glyphs and use that one --switch whose name I forgot when glyphs2ufo-ing.)

Edit: see the bottom of https://gitlab.gnome.org/GNOME/cantarell-fonts/blob/master/src/Cantarell.designspace.

cjdunn commented 5 years ago

@madig I have noticed this "skipExportGlyphs" option, but sadly it only works when using .glyphs files. I would love to see support for this in fontmake for .ufo masters, especially since .ufo is the open format and .glyphs is proprietary.

@thundernixon if you made something like this which works .ufo I would gladly test it and use it in my workflow. Not sure how much I can contribute to the coding itself, but I would definitely support this addition for fontmake.

Some questions: What happens when 3 out of 4 masters are compatible for var fonts? Do you A) drop that glyph completely? Or do you B) just drop the incompatible glyph from that 1 incompatible master (essentially replacing it with the default) and keep the 3 masters which are working? I could see cases when both options are desirable. Many times 3 out of 4 is all I need working to quickly test something new. Since --skip-incompatible would be an opt-in argument I'd love to have option B) as the default. And perhaps option A), if needed, would be --skip-incompatible-strict or something like that? Does that make sense?

anthrotype commented 5 years ago

it's not true that skipExportGlyphs only works when using .glyphs file. It's actually implemented in ufo2ft. Either a UFO's lib.plist or a DesignSpace' lib element can contain that list. @madig also documented this in both the UFO and DesignSpace specifications. https://github.com/unified-font-object/ufo-spec/pull/84 https://github.com/fonttools/fonttools/pull/1534

cjdunn commented 5 years ago

@anthrotype awesome! I will try again then with my .ufo project : )

madig commented 5 years ago

@cjdunn see e.g. https://gitlab.gnome.org/GNOME/cantarell-fonts/blob/master/src/Cantarell-Regular.ufo/lib.plist#L3698-3714

If one master is incompatible, take it out of the Designspace, as it can contribute no useful information.

thundernixon commented 5 years ago

Awesome to learn about public.skipExportGlyphs! I'll need to give this a try. Maybe varfont-prep could just add incompatible glyphs to this list, rather than copying and editing UFOs...

@madig It sounds to me like CJ is saying that just one (or a few) glyphs are incompatible in a master, while most of that master is compatible (and therefore contributes a lot of useful information). Unless, do you mean there's some way to exclude a master for a particular glyph?

madig commented 5 years ago

No useful way that I know of, at least not for generating a variable font through varLib.