fonts April 2020

fonts@lists.fedoraproject.org

2 participants
2 discussions

Request to package: HanYang Gothic A1 fonts
by Artur Iwicki 13 Apr '20

13 Apr '20

Hi. I'm currently in the process of packaging [1] OpenSurge, which is a 2D platformer game [2]. The game bundles the HanYang Gothic A1 fonts. The Packaging Guidelines say to avoid bundling fonts in packages [3], but well, I've never packaged fonts before, and the Font Guidelines are quite long, so I thought I'd ask if anyone would be willing to have a shot at this. The designer's website [4] is in Korean, which I don't speak, so that complicates matters a bit. Looking around the internet, the Google Fonts page [5] says that the fonts are subject to the SIL Open Font License, so they should be ok to include in Fedora. Thanks in advance, A.I. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1823117 [2] https://opensurge2d.org/ [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_avoid_bundling_… [4] https://hanyang.co.kr/ [5] https://fonts.google.com/specimen/Gothic+A1

1 0

[HEADS UP] Working fontconfig validation in rawhide
by Nicolas Mailhot 02 Apr '20

02 Apr '20

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.000… 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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts April 2020