font-metainfo-but-no-font error on valid font packages

[balasankarc]

[Apologies if this issue tracker is not the right place for this query]

I maintain the following font packages in Debian

fonts-smc-anjalioldlipi
fonts-smc-chilanka
fonts-smc-dyuthi
fonts-smc-gayathri
fonts-smc-karumbi
fonts-smc-keraleeyam
fonts-smc-manjari
fonts-smc-meera
fonts-smc-rachana
fonts-smc-raghumalayalamsans
fonts-smc-suruma
fonts-smc-uroob

All of them have similar appstream XML files, but I am seeing both Debian and Ubuntu appstream reports showing the font-metainfo-but-no-font error for many of those packages. For example, consider the package fonts-smc-dyuthi.

$ apt-file list fonts-smc-dyuthi
fonts-smc-dyuthi: /etc/fonts/conf.avail/67-smc-dyuthi.conf
fonts-smc-dyuthi: /etc/fonts/conf.d/67-smc-dyuthi.conf
fonts-smc-dyuthi: /usr/share/doc/fonts-smc-dyuthi/README.md
fonts-smc-dyuthi: /usr/share/doc/fonts-smc-dyuthi/changelog.Debian.gz
fonts-smc-dyuthi: /usr/share/doc/fonts-smc-dyuthi/copyright
fonts-smc-dyuthi: /usr/share/fonts/truetype/malayalam/Dyuthi-Regular.ttf
fonts-smc-dyuthi: /usr/share/metainfo/in.org.smc.dyuthi.metainfo.xml

$ fc-scan /usr/share/fonts/truetype/malayalam/Dyuthi-Regular.ttf | grep "fullname:"
        fullname: "Dyuthi"(s) "Dyuthi Regular"(s)

$ cat /usr/share/metainfo/in.org.smc.dyuthi.metainfo.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2019 Swathanthra Malayalam Computing <contact@smc.org.in> -->
<component type="font">
  <id>in.org.smc.dyuthi</id>
  <metadata_license>CC0-1.0</metadata_license>
  <project_license>OFL-1.1 OR (GPL-3.0-or-later WITH Font-exception-2.0)</project_license>
  <name>Dyuthi font</name>
  <name xml:lang="ml">ദ്യുതി അക്ഷരസഞ്ചയം</name>
  <summary>Dyuthi Malayalam Unicode font</summary>
  <description>
    <p>
      Unicode font for traditional Malayalam script designed by Hiran
      Venugopalan maintained by Swathanthra Malayalam Computing. Ornamental
      font suitable for titles.
    </p>
  </description>
  <update_contact>contact_at_smc_org_in</update_contact>
  <provides>
          <font>Dyuthi Regular</font>
  </provides>
  <languages>
          <lang>ml</lang>
  </languages>
  <url type="homepage">https://smc.org.in/fonts</url>
  <url type="bugtracker">https://gitlab.com/smc/fonts/dyuthi/issues</url>
  <metadata>
  <value key="FontSampleText">മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും അന്തസ്സോടും
         സ്വാതന്ത്ര്യത്തോടും കൂടി ജനിച്ചവരാണ്. അന്യോന്യം ഭ്രാതൃഭാവത്തോടെ പെരുമാറുവാനാണ്
         മനുഷ്യന്നു വിവേകബുദ്ധിയും മനസ്സാക്ഷിയും സിദ്ധമായിരിക്കുന്നത്.</value>
  <value key="FontIconText">അഇ</value>
  </metadata>
</component>

As seen, the appstream XML file does have a <provides>...<font> directive, the package does include the font, and the font name matches what is given in XML file. Still, https://appstream.ubuntu.com/groovy/main/issues/fonts-smc-dyuthi.html and https://appstream.debian.org/sid/main/issues/fonts-smc-dyuthi.html reports the font-metainfo-but-no-font error for the package.

Other packages with the same issue are

fonts-smc-anjalioldlipi
fonts-smc-chilanka
fonts-smc-gayathri
fonts-smc-karumbi
fonts-smc-manjari
fonts-smc-meera
fonts-smc-rachana

What is more interesting is that this issue does not happen on 4 packages, which follow the same XML syntax - fonts-smc-uroob, fonts-smc-raghumalayalamsans, fonts-smc-keraleeyam, and fonts-smc-suruma.

[ximion]

I can reproduce this here, but the issue is in your metadata (it is a bit tricky to see though!). Please validate your data with appstreamcli validate <metainfo.xml> before adding it, that catches the biggest issues. For example, the metadata tag isn't valid and will not be read, so anything in there is ignored (which for this font in particular will be undesirable). You probably wanted to have a custom tag there instead.

Furthermore, as per https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Fonts.html#tag-font-provides the name of the font in its provides name should be its (first) full name - the family/style combo is a fallback in case the font author forgot to set a full name.
You can use fc-query --format='FN: %{fullname[0]}\nFS: %{family[0]} %{style[0]}\n' FONT-FILENAME on a font file to give you exactly the value you need (take the one after FN unless it's empty, in which case the value after FS is used).

For this particular font, its first known name is actually "Dyuthi" and not "Dyuthi Regular" for some reason.
So, the updates metainfo file should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2019 Swathanthra Malayalam Computing <contact@smc.org.in> -->
<component type="font">
  <id>in.org.smc.dyuthi</id>
  <metadata_license>CC0-1.0</metadata_license>
  <project_license>OFL-1.1 OR (GPL-3.0-or-later WITH Font-exception-2.0)</project_license>
  <name>Dyuthi font</name>
  <name xml:lang="ml">ദ്യുതി അക്ഷരസഞ്ചയം</name>
  <summary>Dyuthi Malayalam Unicode font</summary>
  <description>
    <p>
      Unicode font for traditional Malayalam script designed by Hiran
      Venugopalan maintained by Swathanthra Malayalam Computing. Ornamental
      font suitable for titles.
    </p>
  </description>
  <update_contact>contact_at_smc_org_in</update_contact>
  <provides>
    <font>Dyuthi</font>
  </provides>
  <languages>
    <lang>ml</lang>
  </languages>
  <url type="homepage">https://smc.org.in/fonts</url>
  <url type="bugtracker">https://gitlab.com/smc/fonts/dyuthi/issues</url>
  <custom>
    <value key="FontSampleText">മനുഷ്യരെല്ലാവരും തുല്യാവകാശങ്ങളോടും അന്തസ്സോടും
         സ്വാതന്ത്ര്യത്തോടും കൂടി ജനിച്ചവരാണ്. അന്യോന്യം ഭ്രാതൃഭാവത്തോടെ പെരുമാറുവാനാണ്
         മനുഷ്യന്നു വിവേകബുദ്ധിയും മനസ്സാക്ഷിയും സിദ്ധമായിരിക്കുന്നത്.</value>
    <value key="FontIconText">അഇ</value>
  </custom>
</component>

This should work. When you validate the file, it will also complain that https://smc.org.in/fonts throws a 404 error, which is indeed true (with a redirect on the website to the default page).
Maybe it's useful to adjust that too ;-)

And yes, this is indeed the right place for suspected bug and questions for appstream-generator :-)
I can also maybe change that error message to include a list of found fonts, to make the problem easier to spot in future.

[balasankarc]

Thanks for the quick response @ximion

For example, the metadata tag isn't valid and will not be read, so anything in there is ignored (which for this font in particular will be undesirable)

This was kinda intentional, knowing that metadata is a GNOME-specific thingy, and not part of appstream spec. 🙂

[ximion]

This was kinda intentional, knowing that metadata is a GNOME-specific thingy, and not part of appstream spec.

Yes, but the values you put in there are not read by anything in GNOME, but are read by appstream-generator (or rather would be if they were in a "custom" tag). Also, the "metadata" thing isn't even used by GNOME anymore and is considered legacy. Also also, this data is stripped away by the generator, so it will never reach any GNOME desktop - and when the custom tag is used, it is used either locally for app-specific metadata, or for a case like this one, where appstream-generator needs extra information.
tl;dr You never ever want to use a "metadata" tag in AppStream, and do want to use a "custom" tag on rare occasions.

Where did you get the idea to use "metadata" from? Maybe there is some documentation piece out there that needs to be fixed. The text on my blog (from 2017!) at least doesn't mention it and suggests using the custom tag when required: https://blog.tenstral.net/2017/09/adding-fonts-to-software-centers.html

[balasankarc]

Where did you get the idea to use "metadata" from?

From memory, I believe it originated when the maintainer of these font packages in Fedora wrote it initially, and they upstreamed it. I couldn't find any other references to why it was used. Anyway I will switch it to custom tags since that is the specification.

do want to use a "custom" tag on rare occasions.

Makes sense. Are FontSampleText and FontIconText the only such custom values that asgen supports? I see only two references to getCustomValue. If there are more, is there a list?

[ximion]

Ah, interesting!

Makes sense. Are FontSampleText and FontIconText the only such custom values that asgen supports? I see only two references to getCustomValue. If there are more, is there a list?

No, those two are the only ones. The "custom" values usually shouldn't be needed, they are really intended for app-specific or vendor-specific additions that don't make sense to have in the specification (like, extra CSS rules for GNOME Software). That's also why asgen will filter the values out using a whitelist (I know some automobile Linux shells have a bunch of extra custom values, those would be whitelisted by the vendor in order to reach the final metadata).

The reason asgen uses the custom tag for this at all is simply that fonts are weird, and really hard to support in a consistent manner, as the metadata within font files is usually really bad - so the metainfo file may have to contain more metadata than the AppStream spec currently permits in order to generate a good-looking result. The FontSampleText and FontIconText keys may become part of the spec at some point, but at the moment they are semi-official extensions (as in: "Let's see how well this works, and maybe we'll add it to the actual specification at some point". Those are also really just hints for the generator, so it knows which texts to render for images.
(Which actually makes me wonder how your "FontSampleText" will look like in the sample image, as it's quite long...)

[balasankarc]

(Which actually makes me wonder how your "FontSampleText" will look like in the sample image, as it's quite long...)

@ximion This was my next question. I know appstreamcli validate can validate the XML file. But is there any way I can locally check asgen's result, and what data it provides to the "clients" (don't know if that is the correct terminology - I meant GNOME Software Centre or KDE's Discover, etc.) from the specified XML file (for example, what does the rendered sample image looks like)?

[ximion]

The only way to check what asgen produces locally would be to run it locally - while asgen has a mechanism to inject metadata for quicker testing, running it still isn't super simple, as some kind of Debian mirror (can be partial and can be a tiny archive) would still be needed. If you want to test a lot of packages I would suggest creating a local repository from them using reprepro/apt-ftparchive and point asgen at that. If you have fewer packages, I would just upload them to Debian and then see what the result looks like (the asgen HTML pages will show you the raw metadata, which includes links to screenshots and icons - or you'd just run gnome-software locally)

[balasankarc]

Thanks for all the info. 👍