Duplicate Noto Tifininagh fonts for script variants in the main ZIP package containing all fonts

[verdy-p]

The current "main" package containing all Noto (also Cousine, Arimo and Tinos) fonts is duplicating "Noto Tifinagh" fonts for script variants with suffixes (Adrar, AgrawImazighen, Ahaggar, Air, APT, Azawagh, Ghat, Hawad, RhissakaIxa, SIL, and Tawellemmet): This occurs in the collections for the following formats: hinted/ttf, unhinted/otf, unhinted/ttf; but not in the "archive" pack

Also reported in https://github.com/google/fonts/issues/4110

[verdy-p]

I also wonder why we need separate fonts: shouldn't we have a single font with mappings to Unicode variant selectors? Or are separate fonts needed for legacy OSes/renderers not implementing Unicode variant selectors, or are there missing Unicode assignments to identify these variants?

Are there missing OpenType features to allow selecting these variants or styles (notably because variants can have confusive glyphs, depending on the region/language/epoch of use)? How is this different from variants in other scripts ?

[E.g. Fraktur and Gaelic in Latin have their own ISO 15924 script code. As well with the Cyrillic, Arabic, and Syriac scripts having separate script codes for some of its styles.]

[As well there are codes for the Jamo subset in Hangul for the horizontal presentation of narrow/tall glyphs used in monospaced terminals without square composition (and not distinguishing leading consonnants from trailing ones, and using legacy code points for compatiblity). And separate codes for Han script styles.]

May be Tifinihagh could also have other ISO 15924 script codes for these known variants, if there are sponsoring organizations to support them.

These script codes could then be mapped to OpenType feature types for style selection (and a request made to the Opentype specification maintainers). This could simplify a lot the correct (automatic) selection of the variant using language/script identification.

And Unicode should probably register character variants (using letters of the base script, plus a "variant selector") to get a unified encoding of documents, supporting all languages using the script. (Then we could pack all these script variants in a single Tifinagh base font, as there are many shared glyphs across all these variants, and deprecate these specific fonts for variants).

[Such additions of ISO 15924 codes and/or character variants in the Unicode variants registry could also be made to other scripts like Lao, Adlam that also have their "rounded" variants.]

[simoncozens]

The original problem is the same as issue #10.

The question of why we need style-specific fonts in the first place is a different one. I don't know the reason for the different variants but by guess is that they are not technically language specific variations but orthographic variations in different regions. (At least that's what the Unicode Standard appears to suggest) So I'm not sure it would be correct to use OpenType script/language codes to distinguish between them; even if we could, selection of font features by language tags in browsers is generally reasonable but in design applications can often be very hit-and-miss.

Similarly, it would of course be lovely to have it all encoded separately in Unicode and be able to build everything into a single font (the current multiple export process and the feature code to support it is fiendishly complex), but requiring everyone to add variant selectors to every single character that has regional variants just because a user wants the text to be displayed in their own variant is also not a great solution and pushes a lot of the cost of localization onto the user.

[simoncozens]

The distribution is now fixed; there's only one NotoSansTifinagh directory.

[verdy-p]

The original problem is the same as issue #10.

The question of why we need style-specific fonts in the first place is a different one. I don't know the reason for the different variants but by guess is that they are not technically language specific variations but orthographic variations in different regions. (At least that's what the Unicode Standard appears to suggest) So I'm not sure it would be correct to use OpenType script/language codes to distinguish between them; even if we could, selection of font features by language tags in browsers is generally reasonable but in design applications can often be very hit-and-miss.

But OpenType includes the support for language-specific variants (with "locl" feature, internally indexed by locale codes). This is also described in various OpenType documents for specific scripts (see for example the "mym2" script feature set for Myanmar). This means that a single font can support language-specific variations. Making the fonits even easier to use (provided that the renderer is instructed with the language to use, from the document, e.g. with BCP47 codes iin lang="" attributes of HTML; note that OpenType however does not use directly BCP47 locale tags, but has defined its own collection of codes (with fixed sizes) for languages or orthographic variants: it's up to the renderer to map the applications' locale codes to OpenType codes, using the specification of OpenType; applications may use also their own locale codes, not necessarily BCP47 but for example Windows LCID; this does not matter much here how this mapping is performed)

[moyogo]

But OpenType includes the support for language-specific variants (with "locl" feature, internally indexed by locale codes). [...] This means that a single font can support language-specific variations.

There is no 1-to-1 mapping between the different Tifinagh styles and BCP47 nor OpenType Language Systems tags. For example the SIL and APT styles overlap in Niger.

Making the fonits even easier to use [...].

The "locl" feature support is pretty limited and is not easy to use in all applications. Separate fonts is the easiest solution that works everywhere for everyone.