[RFA] Your gnu-free-fonts package did not pass QA

Jon Ciesla limb at jcomserv.net
Mon Nov 23 17:06:41 UTC 2009


repo-font-audit wrote:
> Dear packager,
>
> At 20091122T202901Z, your “gnu-free-fonts” package failed one or more of the tests
> I was performing on the “fedora-devel” repository located at:
> http://koji.fedoraproject.org/static-repos/dist-f13-build-current/x86_64/
>
> There are three different reasons that may cause this message:
> 1. your package is including one or more font files, but not packaging
>    them properly;
> 2. your package is including one or more font files, and I've found
>    issues in some of them;
> 3. your package is not shipping any font file, but the way it accesses
>    fonts in other packages is not satisfying.
>
> To stop receiving this message, you need to:
> 1. drop the font files or fix their packaging;
> 2. relay the fonts issues to the fonts upstream to get them revised;
> 3. work with the code upstream to improve the way it accesses font
>    files (usually by making it use fontconfig through a higher-level
>    text library such as pango, pango-cairo, harfbuzz, or QT)
>
> You can self-check your packages at any time by:
> 1. installing createrepo and fontpackages-tools:
> # yum install createrepo fontpackages-tools
> 2. putting your packages and any font package they depends on in a
>    test directory
> 3. indexing this directory with createrepo:
> $ createrepo path-to-test-directory
> 4. running repo-font-audit:
> $ repo-font-audit test file://absolute-path-to-test-directory
>
> A summary of the issues I detected is appended here. For your
> convenience a more comprehensive analysis is also attached to this
> message.
>
> Errors, warnings and suggestions:
>
> P#     t5  t13  t17  t19  t20
> 1      4   1    4    4    4
> 2      4   1    3    4    1
> 3      4   1    ‧    3    4
> Total  12  3    7    11   9
>
> P#  Maintainer  SRPM            RPM                   EVR                 Arch
> 1   limb        gnu-free-fonts  gnu-free-mono-fonts   0:20090104-11.fc12  noarch
> 2   limb        gnu-free-fonts  gnu-free-sans-fonts   0:20090104-11.fc12  noarch
> 3   limb        gnu-free-fonts  gnu-free-serif-fonts  0:20090104-11.fc12  noarch
>
> Test explanation:
>
> t5. Error: font faces duplicated by different packages
>
>   ☛ Packager task, eventual upstream task
>   
>   Several packages duplicate font files with the same face name. This
>   needlessly wastes resources infrastructure and user side and makes font
>   maintenance problematic:
>   
>   1. Very often an upstream that copied some fonts will forget to keep them
>   up to date, and the duplication will result in the distribution of old
>   buggy data.
>   
>   2. Shipping the same font in different formats is also problematic:
>   different font formats have different features, and are processed by
>   different font libraries. It is almost impossible to create a font in
>   multiple formats that will all behave the same. Users hate fonts that do
>   not behave consistently everywhere.
>   
>   3. Most of our applications use fontconfig to access fonts, and fontconfig
>   uses font names to identify files. Naming collisions make font selection
>   unreliable. So even genuine forks with different features from the
>   original are a problem if not renamed.
>   
>   A repository should always include only one version of a font face.
>   
>   This test can not discriminate between packages and identity the correct
>   owner of the font face. His maintainer will be blamed with others. If
>   you're not him it is therefore unfriendly not to fix this error as soon as
>   you can.
>   
>   It is always possible to reuse a font file packaged separately by adding a
>   dependency on the other package providing it, and accessing the font
>   through fontconfig.
>   
>   If an application can not use fontconfig today this is a serious bug that
>   should be reported to the application upstream. Please ask it to add
>   fontconfig support to their code (usually, via a higher-level library
>   such as pango-cairo). However it can workarounded by the packager with
>   symlinks (that will need maintenance).
>   
>   If an application can not use a modern font format and forces the
>   re-packaging in an older format of an exiting font this is an application
>   bug that should be reported to the application upstream. In that case
>   these is no good solution possible baring the fixing of the application.
>   
> t13. Warning: bad font naming
>
>   ☛ Font upstream task, with packager workarounds
>   
>   The font naming declared by one or more files in the package is not a
>   canonical WWS¹ naming or has some other naming problem. As noted by Adobe²
>   the W3C CSS font family model used in WPF/WWS is less than ideal, but it is
>   a standard and applications expect it.
>   
>   This script attempted to apply some heuristics to fix this naming, and
>   computed different values than those in the font files.
>   
>   That means some of those files are using non-standard, fuzzy,
>   self-conflicting, confusing names. A correct naming:
>   1. only includes “Width”, “Weight”, “Slant” qualifiers in its style name;
>   2. does not declare more than one of each;
>   3. declares them using the canonical keywords defined in the WWS paper;
>   4. declares them in “Width”, “Weight”, “Slant” order;
>   3. uses spaces to separate them;
>   4. does not use “Width”, “Weight”, “Slant” qualifiers in its family name;
>   5. does not use symbols such as & that cause problems in SGML/XML/HTML
>   contexts.
>   
>   The canonical naming computed by this script was printed at test time.
>   Please note that it is only correct in a formal sense: no attempt was made
>   to check that the computed naming corresponds to actual font
>   characteristics. It still needs human review (when the computed naming is
>   way off however that usually indicates the original naming is particularly
>   bad and confusing).
>   
>   Because the aim of this test is to help improve overall font naming it will
>   not accept some user-unfriendly naming exceptions Microsoft handles in its
>   WPF heuristic. Also, the naming parsing used in this test is more aggressive
>   than the one Microsoft uses, so it will manage to “fix” some names WPF can
>   not, at the expense of a few false positives³.
>   
>   The average application is not as smart as this script and will not attempt
>   to “fix” font naming in any way. Therefore, even if this script computed a
>   correct naming, you should not rely on applications doing the same. Please
>   ask the font usptream to fix the naming directly in the font file(s).
>   
>   Packager workaround: patch the file (if it is available in .sfd format),
>   or add a fontconfig rule to your package to hide the problem⁴.
>   
>   ¹ http://blogs.msdn.com/text/attachment/2249036.ashx
>   http://blogs.adobe.com/typblography/typotechnica2007/Font%20names.pdf
>   ² http://blogs.adobe.com/typblography/atypi2006/CSS%20&%20OT%2015.pdf
>   ³ For example the family name may include some words that look like a
>   “Width”, “Weight”, “Slant” attribute, but that are used in a different
>   sense. This script is not a natural language parser and can not detect
>   those cases reliably
>   ⁴ cf the “fontpackages” remapping template; unfortunately this workaround
>   won't fix problems for non-fontconfig applications, or when
>   interoperating with other systems.
>   
> t17. Warning: fonts that do not pass fontlint sanity checks
>
>   ☛ Font upstream task
>   
>   Fontforge's fontlint¹ test suite found problems in some files included in
>   the package. Those problems may not be obvious and only manifest as
>   strange behaviour in specific applications (making them hard to debug).
>   For that reason it is recommanded to report those problems upstream and
>   get them fixed, even if the font file seems to work fine most of the time.
>   
>   You can ask help about specific fontlint errors on:
>   https://lists.sourceforge.net/lists/listinfo/fontforge-users
>   
>   Please relay the problem report to the font upstream.
>   
>   ¹ http://fontforge.sourceforge.net/fontlint.html
>   
> t19. Suggestion: fonts with partial script coverage
>
>   ☛ Font upstream task
>   
>   Some font files included in the package are missing a few glyphs to be
>   accepted by fontconfig as covering one or several scripts. Therefore they
>   could be made useful to more people with only a little effort.
>   
>   Many scripts differ by only a few glyphs and it is unfortunately common
>   for font authors not to notice they stopped just short of full support for
>   some of them.
>   
>   To check a font file script coverage, run:
>   $ FC_DEBUG=256 fc-query font-file
>   and look for lines like:
>   script-id¹(number) { list-of-unicode-codepoints }
>   
>   For example
>   “mi(2) { 1e34 1e35 }”
>   means fontconfig will accept the tested file for Maori if codepoints 1e34
>   and 1e35 are added.
>   
>   fontconfig is used by a lot of applications on many systems so ignoring
>   its opinion on a font is a mistake.
>   
>   Please relay the incomplete coverage report to the font upstream.
>   
>   P.S.
>   Of course fontconfig is not perfect either so it may require a glyph for a
>   script when it should not. In that case, please report the problem to
>   fontconfig upstream:
>   https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
>   against the “orth” component.
>   
>   ¹ http://www.loc.gov/standards/iso639-2/php/code_list.php
>   ² https://bugs.freedesktop.org/enter_bug.cgi?product=fontconfig
>   
> t20. Suggestion: fonts with partial unicode block coverage
>
>   ☛ Font upstream task
>   
>   Some font files included in the package are missing only a few glyphs to
>   fully cover an Unicode block. Therefore they could be made useful to more
>   people with only a little effort.
>   
>   The Unicode consortium revises its tables regularly. A font may need to be
>   extended to maintain full coverage of a block when a new Unicode standard
>   revision is published¹.
>   
>   To check the unicode coverage of a font, run the ttfcoverage command. (It
>   only works for modern .otf or .ttf fonts).
>   
>   Please relay the incomplete coverage report to the font upstream.
>   
>   ¹ http://www.unicode.org/charts/
>   
>
> Please take the appropriate measures to fix the “gnu-free-fonts” package.
> I will warn you again if it is still necessary next time I am ran.
>
> This report was generated by the repo-font-audit command from:
> http://fedoraproject.org/wiki/fontpackages
>
> Please post questions, suggestions, patches or bug reports to:
> https://www.redhat.com/mailman/listinfo/fedora-fonts-list
> (subscription required)
>
> Your friendly QA robot,
>
>   
I understand some of the others, but, Nicholas, did we not just finish 
converting this from freefont to gnu-free-fonts and bringing it into 
compliance with the guidelines in time for F-11?

Am I missing something, or did the font guidelines change *again*?

-J

-- 
in your fear, seek only peace
in your fear, seek only love

-d. bowie




More information about the devel mailing list