----- Mail original -----
De: "David Kaspar [Dee'Kej]"

> * Regarding the font family names and subpackages -- it's another mess.
> Not just in Fedora (the FPG for fonts are really outdated), but generally

> everywhere.

Since I wrote those, I'd like to qualify this:

1. Fedora basic packaging principles for fonts are sound, since they are based around fontconfig capabilities, OpenType capabilities, and the CSS model (mostly the same thing since fontconfig is architectured around OpneType and the CSS font model). All of those are pillars of any font-manipulating app in Fedora currently and in the near future. If anything they've become stronger requirements since the guidelines were written. The basic CSS font family is a set of faces that only differ in width, weight or slant. Because apps can only apply width, weight or slant attributes to text (not serif or sans-serif or whatever). Since in the past years some advanced apps have gained the ability to select optional opentype features such as advanced ligatures, I'd tend to think files that add those features also belong in the same font family.

2. Those principles are much better than the Debian ones of a few years ago, that reposed on layers of custom Debian-specific metadata that was supposed to work with every possible font system, working well with none, all very maintainer-intensive. I haven't checked if Debian managed to sort this mess since. What I've seen of the Appstream font spec reeks of the same metadata overlaying, and misunderstanding of the CSS font model. When you reinvent the wheel you can redefine everything. Contrariwise, when you reinvent the wheel you need to maintain your wheel ad vitam eternam + deal with every piece of code not written around your square wheel. Apps are written around fontconfig and the CSS model, not the appstream abstraction, even when developers do not realise it (the CSS model is really pervasive, since it was defined by Microsoft around what monsters like Office did at the time, and has been adopted by the web and web-derived techs since). Even TEX that long stood for its own font model has switched to OpenType lately – gaining access to the vast trove of OpenType fonts trumped being "better" with a limited font set.

3. Therefore, I would caution against anything that proposed abandoning the CSS font model and redefined the font family/font faces split of the CSS model. A strength of our guidelines is that our package split follows a logical font family split which is understood both by users and the application code.

4. However there are many broken fonts out there. The metadata of actual font files may be suboptimal upstream, requiring font packagers to understand the limits of ideal (application-wise) font families, and fixing the metadata of the fonts we ship either by patching the fonts of via fontconfig directives. This is a major PITA but we can't avoid it if we want the fonts we ship to work well in apps. So :
– font files differ only in width, weight, slant, or optional OpenType features → same font family, belongs in the same package
— font files differ in another stylistic attribute → different font families in practical terms, the best and most advanced app will still treat them as different (even if they have a close human name such as DejaVu Sans and DejaVu Serif)
– font files are split by encoding or region → they still are a logical unit that belongs in a single package. Helping people install part of a font is a source of multiple bugs (that disincentives checking that all the parts wall together, and is an i18n disaster)
– the metadata says otherwise, because of legacy technical limitations or because the font author was confused → the metadata needs to be fixed, either by patching the font or via fontconfig overrides (and past fontconfig maintainers worked with us to define good templates for those)

Now, for the bad part of our font packaging:

— all Fedora font packages were not converted a few years ago. Some maintainers proved resistant (gs is a good example) and I got tired of nagging them.

– it's been a long time anyone checked all the distro font packages. It's unfortunately probable some FPG deviations have been introduced since, because the packagers didn't understand the guidelines, were confused by broken upstream font metadata, or cargo culted special font formats (most everything works with OpenType nowadays, including CSS fonts. IE6 is deader than dead).

— someone need to figure an appstream style compatible with our guidelines, document it and make it part of our packaging

– we couldn't go as far as I wanted last time due to rpm limitations. rpm has improved a lot since. It would be worthwhile to revisit macros and scriptlets to take advantage of new rpm features I think this does not require patching individual packages since the macros are centralized in one place

— likewise, fontconfig improved. It would be nice to change the autoprovides to take the fontconfig files shipped in the package into account, which was not possible in the past. Right now rpm evaluates the font against minimal system fontconfig rules, that the package itself is likely to override.

– a lot of the font packaging tooling was broken by the dnf migration, it needs refreshing (I haven't found the time to do it yet, I suck loads, feel free to replace it with something better).

– likewise the packaging templates need to be refreshed with general FPG changes of the past years (nothing critical, just a general refresh).