4:55 p.m.
Hi all,
Now that Fedora fonts packaging guidelines have been switched to
standard macro calls like %fontcheck, is is possible to fix problems in
a central place, without relying on boilerplate missing in 3/4th of our
specs.
One of those longstanding problems, is the lack of validation of the
fontconfig files our packages ship. Basically, we’ve not checked the
xml files we ship in a systematic way for ~17 years.
And we could not check them because we shipped a broken DTD file and
broken DTD references in the conf files (a relative path, that stopped
working when fontconfig configuration was split over multiple files,
some in /etc, others in /usr/share, yet others in $XDG_CONFIG_DIRS, and
do not forget %buildroot fakeroot in mock copr and koji).
This is now fixed upstream and in Fedora.
1. The dtd file is fixed.
2. It is registered in /etc/xml/catalog.
3. xmllint should work regardless of where the fontconfig file exists
on the filesystem.
Example:
$ xmllint --loaddtd --valid /etc/fonts/conf.d/57-dejavu-sans-fonts.conf >/dev/null
/etc/fonts/conf.d/57-dejavu-sans-fonts.conf:37: element famili: validity error : No
declaration for element famili
<famili>DejaVu LGC Sans</famili>
^
/etc/fonts/conf.d/57-dejavu-sans-fonts.conf:41: element alias: validity error : Element
alias content does not follow the DTD, expecting (test? , family* , prefer? , accept? ,
default?), got (famili accept )
</alias>
^
And the validation is now applied by default for new F33+ font package
builds. Example:
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.WkhT0G
+ umask 022
+ cd /builddir/build/BUILD
+ cd CharisSILCompact-5.000
+ grep -E '^"/usr/share/fontconfig/conf.avail/.+\.conf"'
/builddir/build/BUILD/CharisSILCompact-5.000/sil-charis-compact-fonts.list
+ xargs '-I{}' -- sh -c 'xmllint --loaddtd --valid --nonet
'\''/builddir/build/BUILDROOT/sil-charis-compact-fonts-5.000-4.fc33.noarch{}'\''
>/dev/null && echo
/builddir/build/BUILDROOT/sil-charis-compact-fonts-5.000-4.fc33.noarch{}: OK'
/builddir/build/BUILDROOT/sil-charis-compact-fonts-5.000-4.fc33.noarch/usr/share/fontconfig/conf.avail/62-sil-charis-compact-fonts.conf:
OK
https://kojipkgs.fedoraproject.org//packages/sil-charis-compact-fonts/5.0...
Given how much effort we’ve expended over the years fixing existing
configuration files manually, I don’t expect validation to find a lot
of old problems. However, it will be useful when modifying those files
(or when writing new ones, including private conf files).
Now did I write that one reason it did not work was a problematic DTD
declaration everyone cut and pasted? I did. Existing (Fedora, and
upstream, and private) config files will probably not pass validation
just because they do not declare their DTD the right way.
For validating tools to work, you need to change:
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
into:
<!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
(the urn: thing tells XML it’s an opaque ID, not a relative path;
otherwise tools will attempt to read a fonts.dtd file in the same
directory)
Example of failure in koji:
+ xargs '-I{}' -- sh -c 'xmllint --loaddtd --valid --nonet
'\''/builddir/build/BUILDROOT/dejavu-fonts-2.37-10.fc33.noarch{}'\''
>/dev/null && echo
/builddir/build/BUILDROOT/dejavu-fonts-2.37-10.fc33.noarch{}: OK'
/builddir/build/BUILDROOT/dejavu-fonts-2.37-10.fc33.noarch/usr/share/fontconfig/conf.avail/20-unhint-small-dejavu-sans.conf:2:
warning: failed to load external entity
"/builddir/build/BUILDROOT/dejavu-fonts-2.37-10.fc33.noarch/usr/share/fontconfig/fonts.dtd"
<!DOCTYPE fontconfig SYSTEM "../fonts.dtd">
^
/builddir/build/BUILDROOT/dejavu-fonts-2.37-10.fc33.noarch/usr/share/fontconfig/conf.avail/20-unhint-small-dejavu-sans.conf:3:
validity error : Validation failed: no DTD found !
<fontconfig>
^
Someone tried to fix the relative path at some past date by adding a
../ except that does not work in %{buildroot}; BTW here someone at some
past date is me 10 years ago.
So, if you hit this, just fix the DTD reference to
urn:fontconfig:fonts.dtd and things will work if the configuration file
is clean.
CAN I AVOID CHANGING THE REFERENCE?
You can as long as you do not validate the file. Things will work as
well (or as bad) as they did before. If you package the file, however,
we *will* validate it as part of building the font package.
DOES IT PREVENT USING NEW CONF FILES IN OLDER RELEASES?
Older releases do not validate (validation was broken anyway). You can
inject files with the new DTD reference, they will accept them without
problems.
DOES IT PREVENT SHARING CONFIG FILES WITH OTHER DITROS AND SYSTEMS?
Nope. For the same reason as before: validation was broken everywhere.
The DTD reference has been fixed upstream, everyone will get the same
for new fontconfig deployments, be it on Fedora, Ubuntu, or Windows.
That’s why the reference was fixed to use an URN, and not a system-
specific absolute path, or a network URL (that would have required
upstream to set up a stable & available URL, that would have been
blocked in koji and on some user networks).
CAN IT NOT BE FIXED IN A SINGLE PASS IN FEDORA GIT?
The config files included in fontconfig are now fixed. However there
are lots of fontconfig files floating out there, in font projects, in
various upstreams, on user systems, and years of fontconfig
documentation, referencing "fonts.dtd" without the urn protection. And,
a lot of people do not validate (*we* did not validate for years).
Just remember: if validation tools do not find the fontconfig dtd, just
change its reference to "urn:fontconfig:fonts.dtd". That’s a trivial
fix. It will just take a few years for the swamp to drain.
Regards,
--
Nicolas Mailhot