[makeotf] UFO features.fea file will always be preferred

[benkiel]

As noted here: a30fbae#commitcomment-32676890

With that change the default behavior of makeotf has switched from the feature file outside a UFO being preferred to the one inside being preferred. That's a breaking change — and should at least be strongly noted.

I'm not so sure I like this change, and would like to see the old behavior back; but also understand that the new behavior may be preferred.

[miguelsousa]

Sorry Ben, didn't expect this to cause a big problem.
What is your use case for having a features.fea file inside the UFO and preferring features or features.fea outside of it?

[benkiel]

I don't know if I have a strong use case, but the way that I've always treated the sources (pfa, ufo, ttf, etc) has been that they are for outlines only, features and other things coming from the external files. I ran into a case where the UFOs I was mastering —after upgrading to the latest version of the fdk— gave unexpected results due to some design time features being in the UFO's features.fea file.

I see the case of "well, those features should have been cleared out...", and I agree, but I think that others may have worked this way in the past too, and if they don't realize what is going to happen, they may quickly remaster something and not realize that the fonts are different because of this change.

Perhaps makeotf should say which features files it is using in the output, at least that would make troubleshooting easier. Something like:
makeotf [Note] used MyUFO.ufo features.fea, features.family to build the font.

And, if you just want to close this out as "won't fix", I 100% understand that too.

[frankrolf]

I can understand what angle Ben is coming from here. All of the overrides happen from outside of the UFO, and this now suddenly is within. While I appreciate the file name change from features to features.fea, the location within the UFO is a bit of a hassle because it is not as easy to get to, and may not be obvious for a first-time user.

[khaledhosny]

I don’t know, but if I’m building a UFO font I expect the features inside the UFO to be used, not some random features.fea file I happen to have in the current directory. For other font formats it is different because there is no standardized way to bundle feature file with the font, but even then I personally prefer to be explicit and always specify -ff option to makeotf.

[frankrolf]

This is simply the historical approach, vs. the possibilities of UFO files.
I’d argue that if you’re doing font production work, there is no “random features.fea file [you] happen to have in the current directory”.
Another example: with makeotf, it is possible to generate a UFO that doesn’t even have family- and/or styleName set, the requirement for the postScriptFontName is just as historically-informed as the features file outside the UFO package.

[khaledhosny]

I’d argue that if you’re doing font production work, there is no “random features.fea file [you] happen to have in the current directory”.

The same can be said about having a feature file inside the UFO font that you don’t actually need.

[benkiel]

Correct: if you come to this from pre-ufo, you are used to the source file to be just a container for outlines and some basic data (PS hint settings, postScripteFontName—I think that's it). So this is at odds with that expectation, especially since this is new behavior. I've been mastering from UFOs from the FDK since that was an option and I never had to think about the features inside of the UFO because of the preference for features over features.fea. Now I need to check for features in the UFO if I don't want them, and everything that I've previously mastered, if it is remastered, needs to be checked. That can be hundreds of UFOs for one project (see Sharp Grotesk).

All that said, I'm ok with this change—I agree that there is great utility to taking advantage of what the UFO allows, but it would be good if there was more of warning about it.

[benkiel]

The same can be said about having a feature file inside the UFO font that you don’t actually need.

I'd argue that there is the case of having design time vs production time feature files

[miguelsousa]

Let me start by saying that my main motivation for a30fbae was to support the file features.fea OUTside the UFO. I ended up changing the preferred features file — to the one INside the UFO — also in that change just because it seemed like a good move at the time. Nonetheless I'm willing to reverse the latter on the basis that:

1. it's a breaking change
2. it's inline with how other overrides work, i.e. "I'm using a features.fea outside the UFO because I want to override the one inside it".

used to the source file to be just a container for outlines and some basic data

That was indeed the goal when support for UFO-as-input-font was added to makeotf. But over the years Frank, Paul and I have been thinking how nice it would be to leverage more of the data contained in UFOs in lieu of using external FEA files. In my mind a30fbae was a positive step in that direction, but it's clear now that any change to support that effort needs to be carefully weighted.

That said, here are the changes I'm planning to make:

• Revert the features file resolution (when -ff option is NOT used) to the following:
  1. file named features in font's directory
  2. file named features.fea in font's directory
  3. file named features.fea inside UFO
• Issue an INFO message reporting which features file will be used

How does that sound?

[frankrolf]

I think that’s a great improvement!

[benkiel]

Agree, a nice solution. Sorry if I threw a 🔧 here

[miguelsousa]

No worries. It's good to have you engaged and I'm glad we could find a solution that satisfies everyone.