fonts February 2020

fonts@lists.fedoraproject.org

1 participants
2 discussions

Fonts packaging policy rewrite proposal
by Nicolas Mailhot 14 Mar '20

14 Mar '20

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

3 7

Re: Qt, GNOME, and fonts
by Nicolas Mailhot 22 Feb '20

22 Feb '20

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

fonts February 2020