Unicode Variation Selectors

[khaledhosny]

I’m trying to convert and font that uses several Unicode Variation Selectors to UFO, but there is no support for them in either UFO or feature files. There is a proposal to support them in feature files but does not seem to be implemented.

Has any one managed to use VS with UFO work flow? Would it be better to add support for them in UFO (may be in lib somewhere?) and let ufo2ft compile it when building cmap or wait for the extended feature files syntax (this would mean feaLib would need to do the cmap table generation itself)?

[anthrotype]

Adding an entry in the UFO lib.plist should be easier to implement, as it does not need changes in FEA specification and parser.
The key could be something like com.github.googlei18n.ufo2ft.UnicodeVariationSequences. The structure could be a dictionary that maps unicode variation sequences (UVS) to glyph names. Each UVS could be encoded as a string containing two space-separated hexadecimal values, one for the base character and one for the variation selector.
This data would be used by ufo2ft's outlineCompiler to generate a format 14 cmap subtable.
When a glyph mapped to a UVS already has a unicode value corresponding to the UVS's base character, then the UVS will be encoded as "default"; othwerwise, it will be "non default".

[adrientetar]

That sounds like something which should go into the feature file, no strong opinion though. What I'd do is:

1. Make a PR to the fea spec using the proposed syntax in the issue you linked
2. Implement in feaLib

I think feaLib's code is relatively easy to work with? cause what Cosimo suggests would only apply to ufo2ft, afaict.

[khaledhosny]

Doing this in ufo2ft has the benefit of simplicity since it already generates the cmap table, doing this in the feature file compiler will mean splitting the cmap table over two places and the complications of having to parse the existing cmap table the the feature file compiler and figuring what parts to keep and what to override.

[moyogo]

ufo2ft doesn’t create a cmap_format_14 so there is nothing to parse, keep or override. No?

[moyogo]

To be honest, we could actually do both: have a lib key for cmaps and have some FDK syntax for it. We already have kerning in the UFO which we translate to FDK syntax.
The advantage there is that we can implement it here quickly and move to the FDK syntax when that is official.

[khaledhosny]

The proposed feature files extension is generic and allows for specifying the whole cmap table or just overriding parts of it and is not limited to UVS. I never liked the kerning duplication and that is a constant source of headache for me, and I think UFO source is a better place for stuff related to cmap table (USV can also be implemented as GSUB substitutions and this is perfectly fine for feature files to handle).

[khaledhosny]

Even if the feature files syntax was limited to UVS, there will still be need to parse the other subtables to decide between default vs. non-default UVS.

[bobh0303]

I see this issue is closed, but I don't know what the answer to the original question is. That is, how do we [today] use VS in a UFO workflow? (Or if we can't do it today, is there any ongoing development effort in this arena?)

[khaledhosny]

unified-font-object/ufo-spec#79