[AppStream] Font metadata improvements

[Nathan Willis]

On Fri, May 25, 2018 at 7:40 AM, Richard Hughes <hughsient at gmail.com> wrote:

> Hi Nathan, sorry for the delay.
>
>
No worries!


> On 29 April 2018 at 11:38, Nathan Willis <nwillis at glyphography.com> wrote:
> > - <reserved_font_name>
>
> Could these be <custom> tags? I don't think we have many
> component-type-specific tags in the format so far.
>

Functionally, of course, the answer is yes. The docs page seems to
discourage custom proliferation; perhaps I'm not clear where that line is.

The docs also say that a vendor prefix needs to accompany <custom> tags;
I'm not sure what that would be for a generalized font tag (i.e., you would
want the tag to be the same for every font package, so there's not a
traditional vendor).

I do realize that not a lot of other component types have engaged in much
or any customization; although I sort of would expect <codec> to need a few
additional bits.

Anyway, regardless, part of the trick here stems from the "fonts are
software and are simultaneously a content element" dichotomy. The general
upstream tags cover the "are software" dimension quite well; the goal is
just to hit the major "content side" metadata points that somebody might
want to filter/search on at the "do I want to install this" point in time.
It still leaves other metadata for post-installation "which of my fonts
works best here" questions.


> > specimen
>
> Could that be a <url type="specimen"> perhaps?
>

Can an <url> point to a local-within-the-package file?  Like <screenshot>
does? If so, then absolutely....  (In fact, I may have described it as an
<url> subtype in the original issue opened; I forget)

Being able to handle a file and a site would be nice. Because there is a
mix, in the wild. Web-based specimen "micro-sites" are certainly on the
rise, but the PDF version is still commonplace. Only a handful of Linux
font packages include these at the moment (since they tend to get buried in
/usr/share/doc/ and forgotten), but the SIL fonts are pretty consistent in
this regard, as are a few other foundries/projects that maintain their own
packages.

A specimen is one of those things that might be useful both in a
pre-installation context and post-installation as well (i.e., with a large
font library, you can't remember them all).


>
> > designer_name
>
> Is that much different to the <developer_name> tag?
>
>
In practice, yes. They may be the same coincidentally; more likely so if
it's a new font.

An easy example - the designer of Zapfino is Hermann Zapf, rather than
whoever maintains the release. The fact that it's a Zapf font is more
relevant than whichever corporate entity publishes the binary (and which
can change over time).

In the docs, <developer_name> is defined as "the developers or project
responsible for development of the project" ... which, well, the wording
sounds a tad odd taken out of context like that, but seems to generally be
used to reference the maintainer or the packager.

It's also quite common to use the designer name as metadata when doing a
historical revival. I believe commercial font resellers use that to group
"Garamonds" or whatever in their search results, since a Designer tag is
defined in OpenType's `name` table. So this one would be analogous to the
Artist Name in an MP3, while we've already got the Track Name from the name
of the font. (Not sure what <developer_name> would correspond to ...
studio, perhaps, but that's probably taking the metaphor too far).


Speaking of pre-installation info ... I hate to do this, but one other
possible tag of value would be something that covers "design language".
This is a (recent?) Microsoft invention in the OpenType `meta` table
(described here:
https://docs.microsoft.com/en-us/typography/opentype/spec/meta ) that
indicates, essentially, what the primary language of the font is. MS uses
it to choose what "quick brown fox" string to show in the Windows font
picker. It might also be useful to users to search on in their package
manager.

If the field is there in the font binary, it's more reliable than just
scraping the Unicode block coverage — a lot of Chinese fonts include Latin,
too, for example. And there can alsways be big differences between an
Arabic font designed for the Arabic language and one designed for Persian,
etc. Just a thought. I don't see anything in the generic tag set that would
correspond ... may need more consideration....

Nate

-- 
nathan.p.willis
nwillis at glyphography.com <http://identi.ca/n8>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/appstream/attachments/20180602/716220bc/attachment.html>