Re: <DKIM> Issues with repo-font-audit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Le Ven 29 mai 2015 02:24, Alexander Ploumistos a écrit :


> And then I fed them to repo-font-audit. That gave me an error (fonts
> in packages that contain non-font data), a warning (fonts that do not
> pass fontlint sanity checks) and a suggestion (fonts with partial
> unicode block coverage). I have uploaded the full test results at [5].
> Seeing that I could not do anything for the warning and the
> suggestion,

You can pass those upstream, it does not necessarily use the same tools as
us. Fedora tests often catch things upstream is not aware of (mostly,
fontconfig coverage or you-only-need-two-more-glyphs to fulfill xx

> I tried to figure out what was the cause of the error, but
> I did not reach any solid conclusion. What is the problem? Is it the
> %doc part of the file, the metadata/fontconfig files or all of them
> together?

At a guess that's the new xml metadata that didn't exist when the scripts
were written. Try without it and if it passes someone needs to write a
patch to repo-font-audit to whitelist it

(the reason the test exists is that lots of packages used to hide fonts in
private directories, so other apps did not seen them, users complained of
lack of fonts, and packagers forgot to check the licensing of those

> That got me worried so, I decided to run a check against the other
> gdouros fonts [6]. Of the seven fonts, repo-font-audit managed to
> check only three of them as it threw some error messages as soon as it
> started [7]. I looked around for the same errors and I found only a
> bug report in [8] about ttfcoverage trying to divide by zero.
> It was closed as irrelevant. Should I file a bug report for that?

Yes, it's a bug in ttfcoverage (it should not crash), but likely in the
font too (unfortunately TEX fonts sometimes contain terrible warts TEX
users workaround in macros, but they still need fixing for use in other
apps and in modern TEX engines that behave more and more like normal apps
on the font side).

> Among the above errors, warnings and suggestions are the three ones
> that I kept getting. So, is repo-font-audit an absolutely necessary
> part of the font package creation process, or is it more of an
> advisory tool and we can get by with just the other checks performed
> by fedora-review?

There are lots of bad fonts out there. For-pay foundries used to
commission studies of on-the-wild fonts to prove they were junkware.
Unfortunately, they were not entirely wrong.

So repo-font-audit should absolutely be used to check the packaging side
(and please when packaging practices evolve fix the tests/add new tests).

On the font side it's more like an advisory – how much you can get fixed
upstream. All the warnings result in breakage in some apps or some
locales, a bug-less font should have none. However, as you've seen, there
is a lot of stuff to fix. People focus on the artistic side (the glyph
curves) forgetting fonts are used by apps and apps need the technical side
right too.

Ironically bigname fonts like Liberation or Droid are the hardest to fix
since after the commission money ran out the professionnal foundry did not
want to extend any effort on them.

FYI Google for example routinely fixes many problems in the fonts it
accepts for the Google Font Service before putting the result online.

> And on a slightly different topic, is it absolutely required to create
> a wiki page for a font package, before it is accepted for inclusion?

It's not a lot of work (mostly cut & pasting + some table filling), and
that gives you a central place to check font state in Fedora instead of
trawling repos and mailing lists to find out which fonts are in and what
people would like to see packaged.


Nicolas Mailhot

fonts mailing list

[Index of Archives]     [Fedora Users]     [Font Configuration]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux