Support richer metadata for font packages

The specification is missing tags for a few pieces of information in font packages that are useful for users at package-installation time.

Certainly there would be almost no end to the possibilities for what could be added, but I believe the following list is minimal for the common use cases.

<reserved_font_name> - The RFN is an optional clause in both versions of the Open Font License. If the designer invokes it in the license, then any modification, including on-the-fly subsetting and compression, triggers the need to rename the font in all potentially user-visible locations. Thus, it can be important to see that a font has a non-NULL RFN while selecting a font; not needing to do the renaming could be important.

Personally, I would advocate that OFL-with_RFN be treated as a separate option from OFL without an RFN, but I think that is technically an issue for SPDX to solve. Regardless, if there is an RFN in the font, it is important metadata. That info could be pulled from the package's license file by string matching the RFN clause.

<designer_name> - In practice, this may be identical to the property for generic packages, when one person designs and releases the font. However, it is common for foundries and individuals to release digital copies of existing designs or revivals of pre-digital typefaces and refer to them by the original designer's name. E.g., "Open Baskerville" is referred to as a Baskerville font, Bitstream Charter is referred to as a Matthew Carter font, etc. For well-known designers, users tend to recall these designers' name (sometimes with more clarity than the font name) and use them as search queries (e.g., "I'm doing a magazine spread and I need a Bodoni for the headline; do I have one?). This property is generally stored in the name table as Name ID 9, so may be automatically determined for many packages.
<foundry_name> - Similarly, type foundries have a name-recognition factor, orthogonal to the packager and to the vendor delivering the font. In the name table this is typically Name ID 8.

Both <designer> and <foundry> could have corresponding <_url>s, too, but perhaps that is overkill at present. Here too there are OpenType NameIDs already in the font binary (12 and 11).

New <url> subtype: <specimen> - Specimens are demonstration documents produced and released by the foundry or designer; in many commercial font releases they are included in downloadable packages. In some cases they might be online web documents, but they are typically PDF files for contemporary fonts. The specimen can serve a variety of purposes, such as purely visual samples or technical feature documentation.

The specimen is not synonymous with the <homepage>; see for example the SIL fonts. Gentium's homepage is http://software.sil.org/gentium/ ; the specimen (for the current release) is http://software.sil.org/wp-content/uploads/sites/20/2015/12/Gentium-RU-Specimen.pdf Technically, Gentium has several specimens; I don't know whether or not that is important to users, but it could be.

I believe <specimen> also to be distinct from the <help> URL, which already exists. That might correspond more to something like https://software.sil.org/gentium/support/smart-font-features/ .

Admittedly, a lot of libre fonts do not have <help>-like documentation at all, but I wish more did and would rather see the number grow than decline.

Finally, I would also contend that <specimen> is distinct from the <screenshots> already available in the specification. It is a document produced by the designer/foundry, meant to stand on its own. Good, non-generic screenshots are always welcome, but the user has different expectations. The specimen is useful if the user wants to see what the designer had in mind, so to speak. Screenshots are expected to get right to the glyphs and be more cut-and-dried.

It would also be beneficial to have some way of tagging a few special-classification fonts, namely "color fonts" and "variable fonts". Possibly "emoji fonts" would fall under this heading, too. Software support for these font types is far from universal and it is likely that they will never constitute a majority of the fonts in the wild. Thus, users looking for one could use some help locating them. Furthermore, we're likely to see people converting existing font families into variable-font versions, so the two might have to coexist in a repository for quite some time.

I've got no recommendation for where this sort of extension would go in the specification. Maybe there just needs to be an extensible <format> tag; it's conceivable that there are other uses, too, such as distinguishing AAT or Graphite fonts, or OpenType-TTF versus OpenType-CFF.

ximion / appstream

Support richer metadata for font packages #168