Should rewind CDATA

[mcrha]

Coming from https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2942

The fonts in Fedora generate AppStream data where summary and description contain CDATA data, like:

  <summary><![CDATA[ADF Accanthis Nᵒ2, a modernized garaldic serif, “Horley old style” alternative]]></summary>
  <description>
    <p><![CDATA[A Latin font family published by Hirwen Harendal’s Arkandis Digital Foundry, Accanthis was inspired from
the “Cloister Oldstyle” font family found in the “American Specimen Book of Typefaces Suplement”. Its medium contrast
is sufficient to be reader-friendly and deliver an elegant and refined experience.]]></p><p><![CDATA[Accanthis is a
modernized garaldic font family and is well suited to book typesetting and refined presentations.]]></p><p><![CDATA[This
variant is closer to the “Horley old style” font family than the original version.]]></p>
  </description>

which the libxmlb does not account for and turns each into (null) when read. The appstream-data package might go through other pipes, I do not know, it's just when I pass such AppStream data directly to gnome-software, which uses libxmlb to work with it, it does not read the CDATA content and behaves like the element is empty. I did not find any XbNode API to get to the CDATA data on the client side, thus I guess it's up to the libxmlb to account for it.

[hughsie]

I don't think that's valid AppStream -- it's certainly going to break a lot more than just libxmlb...

[hughsie]

@ximion opinions welcome here

[ximion]

Indeed, what happened there? Does Fedora still use the appstream-glib-based data generator, because I am 99% sure that both appstreamcli compose and appstream-generator will filter this out, either by rejecting the input if it was in the input, or by sanitizing the output.

[ximion]

@ximion opinions welcome here

Haha, I was already typing 😆 - I think that AppStream might parse this (I would have to test that...), but it would never ever generate anything that contains CDATA as an output.

[mcrha]

The font packages generate such AppStream data (through the font-rpm-macros), then it's dragged forward.

I've a patch for it (libxmlb), it's more or less simple.

[hughsie]

I've a patch for it (libxmlb), it's more or less simple.

I'd be interested to see -- needs tests of course. I think we should be accepting on input in libxmlb, but I do think the appstream generator should also sanitize things like this. Short term the font-rpm-macros need to be fixed -- just because you can do something doesn't always mean you should :)

[mcrha]

I'd be interested to see...

On it.

-- needs tests of course

Of course :)

[mcrha]

Here you are: #291

[hughsie]

Looks great, thanks as always @mcrha

[mcrha]

While talking to you, how does appstream-data generate screenshots for the fonts? It would be good to have a set for light and a set for dark themes, appropriately marked in the AppStream data (more in the gnome-software bug referenced in the description).

[hughsie]

how does appstream-data generate screenshots for the fonts

That's a bit like asking what ingredients go into a sausage. It's essentially this: https://github.com/hughsie/appstream-glib/blob/main/libappstream-builder/plugins/asb-plugin-font.c -- but grab a beverage before you start reading.

[mcrha]

Thanks :)

[ximion]

I think appstream-generator may already do what you want - kind of. It generates icons and cards like these:

So, at least stuff stays readable no matter how the colorscheme of the software-center looks like.
I think Fedora may currently be the only distribution that is still using appstream-glib, I was told that was simply because nobody has had time to do any work on this ;-)

That's a bit like asking what ingredients go into a sausage.

Fonts are their own part of hell... It's not like the asgen code is any more pleasant to read than the asbuilder code 😂😅