Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extra lookup in 'kern' feature introduced in ufo2ft v2.0.0 #280

Closed
miguelsousa opened this issue Sep 28, 2018 · 7 comments
Closed

Extra lookup in 'kern' feature introduced in ufo2ft v2.0.0 #280

miguelsousa opened this issue Sep 28, 2018 · 7 comments

Comments

@miguelsousa
Copy link

I traced this fontmake issue back to changes introduced in ufo2ft version 2.0.0.

When built with ufo2ft v2.0.0, the GPOS table of SourceSansVariable-Italic.ttf contains an additional lookup in the kern feature, by comparison to building the font with ufo2ft v1.1.0.

ufo2ft-1.1.0.ttf.zip
ufo2ft-2.0.0.ttf.zip

ufo2ft-1 1 0

ufo2ft-2 0 0

@anthrotype
Copy link
Member

anthrotype commented Sep 28, 2018

OK, this is a ... feature. It's my fault it wasn't communicated clearly enough.
#187 (comment)

After v2, the KernFeatureWriter by defaults "appends" the generated kerning lookups to the existing ones, previously the default mode was "skip" (which means, don't add kern if it's already present in features.fea).

https://github.com/googlei18n/ufo2ft/blob/c9925b38a103d2396528a5ec0b23d26016969e25/Lib/ufo2ft/featureWriters/kernFeatureWriter.py#L204

This was done to match Glyphs.app's behavior. The rationale is that a user may manually write some kerning lookups in the features.fea (mostly the contextual ones, as font editors AFAIK don't have UI to insert), and then have the auto-generated, regular kern pairs (i.e. from kerning.plist) added to the kern feature as an extra lookup.

So this is the current default for kern (not for mark/mkmk, which still default to "skip" mode).
Now, you have a few options to override this, if you don't want that your existing kern feature (probably generated by some external tool) be modified by ufo2ft feature writer

  1. You can tell fontmake to not generate any automatic features by passing a special --feature-writer None option. This will disable all ufo2ft feature writers (so currently, both kern and mark/mkmk).

  2. you can select which feature writers to use via fontmake's --feature-writer option, instead of the default ones. Say, for example, you want to only generate mark/mkmk, then you pass --feature-writer MarkFeatureWriter, and fontmake will instruct ufo2ft to use that instead of its default list of feature writers. That option can be used multiple times (once for each feature writer class).

  3. You can also customize the feature writer initialization by passing keyword arguments to its constructor in the --feature-writer option. So, you could change the default mode of KernFeatureWriter from "append" to "skip" with: --feature-writer "KernFeatureWriter(mode='skip')". This way ufo2ft will only write a kern feature if it isn't already defined in features.fea (like it was before v2). Note that once you pass the --feature-writer option in fontmake, then you need to explicitly list all the writers that you want to be used instead of the defaults. The user defined list of writers replaces the default one. So if you want to also make mark/mkmk you need to additionally pass --feature-writer MarkFeatureWriter.

  4. Yeah you have many options :). Finally you can store these configuration parameters for the ufo2ft feature writers in the UFO lib.plist itself, so you don't need to pass any option to fontmake.
    Here is an example:
    https://github.com/googlei18n/ufo2ft/blob/c9925b38a103d2396528a5ec0b23d26016969e25/tests/featureWriters/featureWriters_test.py#L26-L41
    It's basically an array of plist dict under a private key "com.github.googlei18n.ufo2ft.featureWriters", each dict contains a (required) class (string), and optional module (defaults to ufo2ft.featureWriters) and options (a dict used to customize the writer's __init__).

I hope this clears the issue. Please let me know if none of these solutions work for you.

@miguelsousa
Copy link
Author

@anthrotype thanks a lot for the thorough explanation. I hope it helps other people as well. I've confirmed that using --feature-writer None fixes it for me.

But I've decided that the best solution is to not upgrade; the changes starting with v2.0.0 don't have any benefits to us, and I also find it worrisome that these and other decisions (e.g. in fontmake) are to cater to the way Glyphs works.

I understand that you make the changes your font-making pipeline requires. And I have to admit that Google has contributed a lot of great font-related code to the community. But don't be surprised if you don't see wide adoption of the latest tools and workflows. I, for one, have been using a fork of fontmake for some time, and issues like this help validate that decision. The biggest problem I see is that the toolset is increasingly getting tailored to a particular way of making fonts.

@anthrotype
Copy link
Member

I've decided that the best solution is to not upgrade

later fontmake requires ufo2ft for that and other features. I'm afraid I don't guarantee it will continue to work with older ufo2ft version.

I, for one, have been using a fork of fontmake for some time

I'm very sorry to hear that. The intention was certainly not to give preference to one specific font editor's workflow over the other. I'm always open to discuss specific issues and find a good compromise. We do want to try keep everybody in the loop.

@anthrotype anthrotype reopened this Sep 28, 2018
@anthrotype
Copy link
Member

I would be OK with changing the default back to "skip" (if present) for the KernFeatureWriter, and have glyphsLib add something to the UFO lib.plist to use "append" instead.
It'd be nice to hear from other people that use fontmake with UFOs, whether they encountered the same issue, or if they rely on the v2 default behavior (which can be handy regardless of the source format).

@miguelsousa
Copy link
Author

The intention was certainly not to give preference to one specific font editor's workflow over the other.

My quibble is not with font editors. I don't really care what font editor people prefer. What I care about is how fontmake handles UFOs, the canonical format for font source storage. In my view, fontmake's main goal should be catering to that format. Catering to the specifics of font editors should be implemented as an add-on/extra that does not interfere with its core functionality.

I would be OK with changing the default back to "skip"

That would be a positive change IMO. If you think about it, the current requirement of using an option just to set a value to None is err... dumb? To me it's clear that None should be the default.

and have glyphsLib add something to the UFO lib.plist to use "append" instead.

Make sure that stuff doesn't get added by default. I don't want to see my UFOs carrying around data that is only required by a library that I don't use. Having glyphLib as a dependency of fontmake is enough unnecessary baggage already; please don't leak that workflow's requirements any further.

which can be handy regardless of the source format

You must be thinking of a specific scenario, because I don't see the benefit of getting the tables mucked with when I explicitly provide all the necessary FEA files.

@anthrotype
Copy link
Member

I decided that we should revert back to mode="skip" as the default for the KernFeatureWriter.
I'm changing glyphsLib so that it will export a custom featureWriters setting in the designspace exported from .glyphs source file. This way, when fontmake builds from a .glyphs source, ufo2ft will still use "append" mode (as that's expected by Glyphs users). Whereas when fontmake builds from plain UFO or designspace (without custom featureWriters settings), it will use the ufo2ft default settings, which will be "skip" for all feature writers.
googlefonts/glyphsLib#441

@miguelsousa
Copy link
Author

Thanks for reconsidering.

anthrotype added a commit to googlefonts/fontmake that referenced this issue Oct 19, 2018
upcoming glyphsLib will store a custom 'featureWriters' key in the generated
designspace <lib> element, so fontmake needs to read that and pass the option on
to the ufo2ft compile functions.

googlefonts/glyphsLib#441

Following discussions in googlefonts/ufo2ft#280, we decided
to revert the default mode for the ufo2ft kernFeatureWriter to skip (if feature already present).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants