@gferreira said in Best way to remove glyph from RFont?: for layerName in f.layerOrder: layer = f.getLayer(layerName) for glyphToRemove in glyphsToRemove: if glyphToRemove in layer: del layer[glyphToRemove] else: print("%s does not contain a glyph named '%s'" % (layerName, glyphToRemove)) Ahhh this makes a lot of sense now, but it's helpful to see the specific way to do it. Maybe it would be worth adding this to the docs, here? https://robofont.com/documentation/how-tos/adding-and-removing-glyphs/?highlight=remove glyphs#removing-glyphs-1 Thanks so much for the help!

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!