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

set custom 'append' mode for ufo2ft KernFeatureWriter #441

Merged

Conversation

anthrotype
Copy link
Member

ufo2ft users did not like that I changed the default mode for the KernFeatureWriter to match Glyphs.app's behavior. It used to be "skip" (only add feature if not already present), but in ufo2ft v2 I changed it to "append" (add new kern lookups to existing kern feature). The idea was to support this use case:
https://glyphsapp.com/tutorials/contextual-kerning

I decided to revert the kernFeautureWriter default back to "skip". But we need to a way from glyphsLib to signal that, when building fonts from .glyphs sources with fontmake, we still wish to have the ufo2ft-generated kern feature appended to manually written kern lookups.

The solution is to store this custom glyphsLib-specific settings in the designspace lib, and have fontmake apply them when calling ufo2ft.

So, in sum, no changes for fontmake users building from .glyphs sources. But a small change to the glyphsLib-exported designspace, only when GSFont has a manually written "kern" feature.

The default mode for ufo2ft kernFeatureWriter is going to change
back to "skip", as that's more common and expected in the UFO world.
Therefore to keep the current behavior (append autogenerated kerning
to any user-defined lookup, usually used for contextual kerning), we
need to tell ufo2ft that we want "append" mode instead.

We store this information in the designspace lib element. Fontmake
will take care of passing that on to ufo2ft compiler, when building
from a designspace that was generated by glyphsLib (or any designspace
actually).
@anthrotype anthrotype merged commit cfef8fb into googlefonts:master Oct 12, 2018
@anthrotype anthrotype deleted the custom-ufo2ft-feature-writers branch October 12, 2018 16:34
@schriftgestalt
Copy link
Collaborator

If you have a custom kern or mark feature, Glyphs will use it as is unless the code contains a # Automatic Code End or # Automatic Code Start comment.

so for example:

# Automatic Code End

pos a b c' <100 0 100 0>;

will be appended to the generated kern feature. It is not just appended, more inserted in the right place depending of the script. The above code will put it below the default latin kerning. if script tags are present it is sorted behind the automatic code for each script. That is because makeOTF allows each script only once per file.

@anthrotype
Copy link
Member Author

@schriftgestalt thanks Georg, I'll see if I can add that to ufo2ft as well, as it seems like a useful feature to have regardless of font source format.

I have a question though: when was this behaviour introduced in Glyphs.app? If I grep for those special comments in the noto-source repository I cannot find them among them, and I'm certain that there are at least a few noto fonts (like Sans Arabic or Sans Tibetan) that I remember define a some manual kern lookups that need be extended with the autogenerated kern feature, and they do not seem to have those special comments.

Does current Glyphs.app not generate automatic kern for these?

@schriftgestalt
Copy link
Collaborator

I just checked again and for kern and dist it doesn’t use the comments. Only for the various mark features.

@anthrotype
Copy link
Member Author

thanks for checking!

anthrotype added a commit to googlefonts/fontmake that referenced this pull request 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

Successfully merging this pull request may close these issues.

2 participants