[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