Thank you for the response. I get it, I think. Address two different problems with the processes for addressing those issues, rather than conflate the code of one problem with the "solution" for the other. Cheers. Now to get the kerning part right!

@frederik I dream of the day someone would convert fontTools feature ast objects to json and we won't use fea file anymore.

and with a script its super easy: # load two fonts fontWithKerning = OpenFont() fontWithoutKerning = OpenFont() # clear and update the kerning with data from # the font with kerning data fontWithoutKerning.kerning.clear() fontWithoutKerning.kerning.update(fontWithKerning) # clear and update the groups with data from # the font with kerning data fontWithoutKerning.groups.clear() fontWithoutKerning.groups.update(fontWithKerning) enjoy!

Thanks for the info.

its been described here https://docs.microsoft.com/en-us/typography/opentype/spec/features_ko#lfbd You can use pos in an feature to position a character or a pair (like kerning) or even contextual move characters around.

As a belated update, I found that the script above didn’t handle Template Glyphs well. It would remove all template glyphs from the font. This current version of the script handles template glyphs: https://gist.github.com/arrowtype/9ef6ce07233af2d80bc0bfb4290d642c

Dear Frederik, thank you for your answer! Why would an alternate version get a unicode value? It’s not allowed to provide two glyphs with the same unicode value. Thinking from a typesetting point of view: which one should it take? I see, so … there’s no problem here, but it’s actually right that the alternates named e.g. A.alt or A.ss01 don’t have the same unicode value as A itself … thank you for clarifying this. I would recommend you to write an OpenType feature to switch the A to the alternate A.ss01 in InDesign: I see! So it seems I’ll try to read the Robofont page on features and the documentation from Adobe and then I can hopefully figure out what to write in that feature file as now it’s completely empty. I mean, maybe this feature files needs to have lines like the following: # Script and language coverage languagesystem DFLT dflt; languagesystem latn dflt; And afterwards I could manually add what you proposed for A–Z and 0–9 in ss01, ss02, and ss03. feature ss01 { sub A by A.ss01; # ... } ss01; I saw something like A.alt in some free and open source .ufo files and was wondering what it is, i.e. why would I write .alt instead of some styleset like .ss01 … EDIT: I just discovered an article about opentype features on i love typography dot com which lists features like aalt “All alternates“, calt “Contextual alternates“, salt “Stylistic alternates”, et cetera (which I already know from CSS). So I think for another stylistic version of the figures 0–9, salt would be a kinda semantically correct feature name.

There are some non-ascii characters in your fea file. You can remove the non-ascii by right-clicking the UFO file and choosing Show Package Contents; open the feature.fea file in a code editor and remove the second line. I hope this makes sense. Or wait until the update is posted. This issue is fixed and will be present in the next update. for your reference: https://github.com/typesupply/ufo2fdk/commit/a792785fb6bd146215d8af8f7a74fbdcad19138b

@frederik I have mailed you a sample UFO file with the feature issue. Hope you have received it.

double posting :) ( https://twitter.com/robofonteditor/status/357071426911600640 ) you can add glyphs and draw a ligature see http://doc.robofont.com/documentation/workspace/font-collection/adding-and-deleting-glyphs/ and use an OT "liga" feature to replace them see http://doc.robofont.com/documentation/workspace/features/ good luck

I don't know the difference! But in fontlab when I open a font, in the kern feature I can see that LTR kerning is interpreted like this: pos uni0631 uni0628 -225; But RTL kerning is interpreted like this: pos uni0631 uni0628 <-225 0 -225 0>; So I suppose RTL kerning should be implemented with adjustments applied to position of the glyph too, maybe I'm wrong; I'm not a pro. (see AFDKO OpenType Feature File Specification) About the kerning in RoboFont, I think there is a malfunction in the "Right to left" Option in the kerning panel. Here is what I do: I open a font which already has RTL kerning, Robofont interprets kerning correctly. I open the kerning panel and click on a class pair, the kerning shows up but order of glyphs is incorrect, I turn the "Right to Left" option on; Nothing Happens! I turn it off, now order of glyphs becomes right, even so the kerning has been implemented in RTL order.

I recommend reading the feature file syntax see http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html Both are warnings your font will work, but both are also easy to fix. I think the FDK warning message is very helpful. good luck!

Will be solved in the next update. Is already patched in the code http://code.typesupply.com/changeset/1166 thanks

super!

Yes, this is easier and does exactly what I want! Thanks Frederik!

it will remove the glyph name from all groups in font.groups and it will remove the kerning pair of one of two is equal to the removed glyph so when a user removes glyph 'A', it will remove (if those settings are enabled): font.kerning[('A', 'V')] font.kerning[('A', 'myKerningGroups')] font.kerning[('V', 'A')]

this is a v1.1 bug and will be solved in the next version there are no print statements anymore captured from FDK after it fails some where (like in your example)

no not yet but all elements to build a Area51 like extension are embedded :)

Good to know there are improvements on this matters, thanks!