Fonts packaging policy rewrite proposal
by Nicolas Mailhot
Hi,
A fonts packaging policy rewrite proposal has been pushed to FPC today:
https://pagure.io/packaging-committee/pull-request/934
It should be clearer, more opinionated, and take into account:
– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the
Harfbuzz consolidation decided at the 2006 Text Layout summit
https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here
It is based on the new fonts-rpm-macros project for automation:
This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of
packaging macros. It started 2 years ago as a fork of fontpackages,
which is the core of our current fonts packaging guidelines.
It will require putting the fonts-srpm-macros package in the default
build root, like is done for other domain-specific packaging macro
sets.
Major additions:
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete
results)
Major removals:
– tools and scripts
– fixing metadata with ttname
Mostly because no one seems willing to maintain those scripts, or port
ttname to python 3.
https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
showcases the new policy on 62 real-world source packages, generating
139 installation packages. Some of those are badly delayed updates to
Fedora packages, others are brand-new packages ready for Fedora
inclusion. They include major font packages such as Stix, DejaVu, Droid,
IBM Plex.
Existing Fedora packages will continue to build, the old fontpackages
macros are grandfathered in fonts-rpm-macros for now. They will be
removed in a few years to give packagers time to apply the new
guidelines.
Regards,
--
Nicolas Mailhot
4 years, 1 month
- 3
- 7
Re: Qt, GNOME, and fonts
by Nicolas Mailhot
Le lundi 17 février 2020 à 16:08 -0700, Jerry James a écrit :
Hi,
> I am trying to track down a font problem with MuseScore:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1790829
>
> The problem is that everything is displayed in Cantarell, no matter
> which font the user actually selects. In the style menu, one can pop
> up a list of fonts to choose from, and even though every font on the
> system is displayed by name, the text samples are all displayed in
> Cantarell.
I’m neither a QT nor Musescore user. However, I know how things should
have been done to work reliably. So I'll put it there and let you find
where one of the app authors though it smart to play fast and loose.
First, Muse Score should install its fonts in the system font store,
use standard unicode points to render, and rely on fontconfig to
compute the best font containing those symbols given user-provided font
preferences. (I suppose, musical symbols Unicode.org range,
https://unicode.org/charts/PDF/U1D100.pdf). Eventually, contributing a
music orth file to fontconfig to make selection easier if none is
present yet.
That would make rendering work regardless of the font family selected,
as long as a font containing music symbols was present on system.
Maybe that’s the case today, or maybe Muse Score relies on non-unicode
fonts (or fonts using a PUA area) in a private directory. Private or
non unicode fonts are begging for breakage, as far as I am concerned.
Second, QT should interface properly with fontconfig and honor its
aliases and fallbacks in its selectors (that wasn't the case a long
time ago, I assume the bugs have been fixed since, but maybe I'm
wrong).
Third, GNOME should go back to using fontconfig directly as it did in
the past, instead of trying to override it with a vanity font declared
in a private non interoperable registry, enforced by overriding default
fontconfig queries in GNOME APIs. (vanity font that could not be
accepted as default font either Fedora or upstream, fontconfig side,
because its coverage is too small, and does not pass any serious i18n
test).
That’s not rocket science, drop a file in $XDG_CONFIG_HOME/fonts
defining the system-ui alias to whatever GNOME wants it to be, and you
get instant interoperability with non-GNOME apps (KDE, GTK, etc). If
the file is already present, do nothing, assume the user already
defined his prefered UI font.
Interoperability means thing like the CSS 4 system-ui selector work in
all compliant browsers without needing a special GNOME frobation.
If you want to be fancy go XDG or fontconfig to define a standard
filename all DE use, so different DEs do not stomp on one another.
Regards,
--
Nicolas Mailhot
4 years, 2 months
- 1
- 0
- ← Newer
- 1
- Older →