Le Ven 29 mai 2015 02:24, Alexander Ploumistos a écrit : Welcome! > 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 locale). > 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 files). > 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 cpan.org [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. Regards, -- Nicolas Mailhot _______________________________________________ fonts mailing list fonts@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/fonts http://fonts.fedoraproject.org/
