[AppStream] Font metadata improvements

[Nathan Willis]

Hi all,

I was wondering if I could solicit some feedback on a few spec additions I
proposed for font-package metadata.

This comes from an issue a couple of months ago:
https://github.com/ximion/appstream/issues/168

The goal is twofold: to offer more font-centric metadata to users prior to
installation, and to help hypothetical font-management utilities track
things about installed fonts.

To be brief, it comes down to three new tags and one new sub-tag:

- <reserved_font_name> : this is a serious license-compliance aid. Reserved
Font Names (RFN) are optional clause invocations in OFL-licensed fonts;
users need to (a) know whether or not the font has declared an RFN
(something that happens in the copyright notice, generally) and (b) be able
to see what that RFN is, if it exists.

- <designer_name> : this is metadata about the design of the font, which is
distinct from the "developer" of the package itself. They MAY be the same
for some fonts, but by no means is that typical. E.g., a user might be
searching for a font by a particular designer ("Matthew Carter", "Firmin
Didot"). This info is likely to be extractable for existing font packages
from the binary itself, although the binary field used certainly isn't
required.

- <foundry_name> : this is akin to designer_name, but reflects the origin /
publisher of a typeface design or digital font. Foundries accrue reputation
distinct from individual designers. This is also already defined as a field
in OpenType, so would be extractable for many font packages.

Finally, the proposed sub-tag is <specimen>, a new variety of <url> that is
distinct from <homepage>. The "specimen" is a (usually long-form)
demonstration document designed to show the font in use. Graphic designers
and publishers use these as references when examining/shopping-for or
selecting a font.

I will contend also that <specimen> is too different from <screenshot> to
be rolled into one. The screenshot for a font is meant to be small and fit
into program UIs; the specimen is a full-fledged document.

Anyway, those are a minimal (I think) set of enhancements that would have a
considerable, positive impact on font-selection and font-management tools
on Linux systems.

Thanks,
Nate

PS - The RFN issue does need to be addressed in SPDX, too, because it is a
compliance concern; I'm working on that separately.

-- 
nathan.p.willis
nwillis at glyphography.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20180429/6ba6d514/attachment.html>