Localized family and style names

brawer commented 7 years ago

The OpenType name table supports localized family and style names. Likewise do font editors such as Glyphs. If the designspace document format supported this, glyphsLib could copy the localized names into the designspace instead of throwing the information away. Proposal:

<instance ...>
    <familyName xml:lang="en">Montserrat</familyName>
    <familyName xml:lang="ja">モンセッラ</familyName>
    <styleName xml:lang="en">Bold</styleName>
    <styleName xml:lang="de">Fett</styleName>
    <typographicStyleName xml:lang="en">Semibold</typographicStyleName>
    <typographicStyleName xml:lang="de">Halbfett</typographicStyleName>
    <location>...</location>
    <kerning />
    <info />
</instance>

The name-related attributes of instance would be handled as if the corresponding element was supplying an English string. For example, <instance familyname="Foo" stylename="Semibold"> would be treated as if the designspace document looked like this:

<instance>
    <familyName xml:lang="en">Montserrat</familyName>
    <styleName xml:lang="en">Semibold</styleName>
</instance>

varLib would probably use the typographicStyleName for naming instances, using styleName as fallback if no typographicStyleName was present.

LettError commented 7 years ago

Interesting! What is the typographicStyleName ?

brawer commented 7 years ago

See https://www.microsoft.com/typography/otspec/name.htm (nameID 16/17).

moyogo commented 7 years ago

stylemapfamilyname and stylemapstylename are already defined for cases when font.info.styleMapFamilyName and font.info.styleMapStyleName names (the legacy names) differ from the font.info.familyname and font.infostylename (the typographic names). So varLib should fall back the other way around.

Wouldn’t it be better if the English names fell back on the attributes of the instance element?

<instance familyname="Montserrat" stylename="SemiBold" stylemapfamilyname="Montserrat SemiBold" stylemapstylename="Regular" ...>
    <familyName xml:lang="ja">モンセラート</familyName>
    <styleName xml:lang="de">Halbfett</styleName>
    <styleMapFamilyName xml:lang="de">Montserrat Halbfett</styleMapFamilyName>
    <styleMapFamilyName xml:lang="ja">モンセラート SemiBold</styleMapFamilyName>
    <styleMapStyleName xml:lang="de">Standard</styleMapStyleName>
    <location>...</location>
    <kerning />
    <info />
</instance>

would be the same as

<instance familyname="Montserrat" stylename="SemiBold" stylemapfamilyname="Montserrat SemiBold" stylemapstylename="Regular" ...>
    <familyName xml:lang="en">Montserrat</familyName>
    <familyName xml:lang="ja">モンセラート</familyName>
    <styleName xml:lang="en">Fett</styleName>
    <styleName xml:lang="de">Halbfett</styleName>
    <styleMapFamilyName xml:lang="en">Montserrat SemiBold</styleMapFamilyName>
    <styleMapFamilyName xml:lang="de">Montserrat Halbfett</styleMapFamilyName>
    <styleMapFamilyName xml:lang="ja">モンセラート SemiBold</styleMapFamilyName>
    <styleMapStyleName xml:lang="en">Regular</styleMapStyleName>
    <styleMapStyleName xml:lang="de">Standard</styleMapStyleName>
    <location>...</location>
    <kerning />
    <info />
</instance>

Maybe these elements should be in the info element.

LettError commented 7 years ago

I think styleMapStyleName is better than typographicStyleName as it already has some use in UFO. I'm puzzling over how these localisations would work in the descriptor object.

Maybe analogous to the glyph.unicode / glyph.unicodes from robofab/fontparts?

instanceDescriptor.styleMapFamilyNames['ja'] = "モンセラート SemiBold"
instanceDescriptor.styleMapFamilyNames['en'] = "Montserrat SemiBold"
instanceDescriptor.styleMapFamilyName = "Montserrat SemiBold"

LettError commented 7 years ago

I've sketched out some support for localised styleName, familyName, styleMapStyleName and and styleMapFamilyName. These values can roundtrip.

I think it would be useful to write these localised names to UFO as well (well, at least to UFO3).

It seems they can be written to font.info. openTypeNameRecords, but that also requires some sort of decision on platformID and encodingID, as we currently only have the name and the language code.

Suggestions?

anthrotype commented 7 years ago

I've sketched out some support for localised styleName, familyName, styleMapStyleName and and styleMapFamilyName.

Looks good to me. We shall add support in varLib to set localised instances names when building fvar using this new stylename element that you sketched out: e.g. https://github.com/LettError/designSpaceDocument/blob/master/Lib/designSpaceDocument/testLocalisedNames_roundtrip.designspace#L39 Maybe we could/should formalise these new elements in the designspace document specification.

I think it would be useful to write these localised names to UFO as well... but that also requires some sort of decision on platformID and encodingID, as we currently only have the name and the language code.

The name table module contains mappings between Windows or Mac langID codes and IETF BCP-47 language tags and the addMultilingualName method looks these up to determine the langID. https://github.com/fonttools/fonttools/blob/588f5246c0b81308172ae91227d5c746d48a0596/Lib/fontTools/ttLib/tables/_n_a_m_e.py#L164 The latter method only adds names for the Macintosh platform when it cannot make a Windows name, e.g. for exotic BCP47 language tags that have no Windows language code.

Note that this is not being used in varLib's fvar builder yet though, we still only add English names (cf. https://github.com/fonttools/fonttools/issues/930)

Maybe designSpaceDocument/mutatorMath can do the same for UFO3 openTypeNameRecords?

LettError / designSpaceDocument

Localized family and style names #9