where's this macro coming from?

@tagoh are you on board?

Just one comment so far about some changes regarding to the WPF font selection model. we should try to implement it in some font packages before asking for acceptance of this change because there might be some side effect on it like we saw some on Google Droid. I'm a bit concerned that. apparently some examples in this proposal implies about Noto though, that is huge families to be unified. that would be nice to avoid regressions as much as possible.

Oh, and this isn't actually a comment on changing the policy but that would be nice to have more flexible rpm macros for complicated font packages like google-noto-fonts. but that may be wrong place to ask.

where's this macro coming from?

It's part of the fonts-rpm-macros set. I did not make the effort to push it in redhat-rpm-config because I only use it in font packages (but there, all the time)

https://pagure.io/fonts-rpm-macros/blob/master/f/rpm/macros.d/macros.fonts-rpm#_145

Oh, and this isn't actually a comment on changing the policy but that would be nice to have more flexible rpm macros for complicated font packages like google-noto-fonts. but that may be wrong place to ask.

@tagoh the rpm side of things is now streamlined and flexible both in the general packaging instructions (the Checklist) and in the packaging macro implementation.

The fontconfig side is in the same state as before (only better and more forcefully documented in the guidelines). The fontconfig templates in fonts-rpm-macros are byte-to-byte identical with the fontconfig templates in fontpackages. They are still limited to the patterns Behdad reviewed and approved in 2007.

So, the guidelines rewrite does not include any improvement fontconfig side. I didn't want to block on hypothetical future enhancements. The existing guideline is in high need of rewrite even without fontconfig changes (to be honest, it's years past its due date, I got busy elsewhere and didn’t update it timely, and no one else did the work).

You know and I know packagers would really love some simplified higher level syntactic sugar fontconfig side, but we've known this for years and things do not seem to improve. We can update the fontconfig templates in fonts-rpm-macros as soon as a better syntax gets available in fontconfig. As for the previous packaging implementation, you're admin of fonts-rpm-macros in pagure.

We're finally wrapping up the task list defined around 2006, with pango and others finishing their migration to harbuzz-ng. It would be nice to start working on a new and improved text target. The guidelines can be updated when this target gets defined.

@tagoh

Just one comment so far about some changes regarding to the WPF font selection model. we should try to implement it in some font packages before asking for acceptance of this change because there might be some side effect on it like we saw some on Google Droid

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
includes those "some font packages". It's really not different from the past decade of Fedora Droid packaging, so there was a lot of time to iron out things (and they won’t get easier to iron out as more complex fonts get released upstream and packaged in Fedora).

Microsoft uses this model in its apps, it's included in the OpenType standards, it's getting done with or without us, so surely it's better to acknowledge this is the state of OpenType upstream and things that need fixing or improving infra side (if any) should be fixed. 12 years ago WWS was a new and forward-looking thing. It's not anymore.

Starting with Fedora 31, bitmap non-OpenType fonts are not found by Pango-based applications: https://bugzilla.redhat.com/show_bug.cgi?id=1753295. However, while producing OTB format using fonttosfnt makes them available, there are spacing issues with them (even with patched fonttosfnt), so the fonts are not really usable.

So far we don't have a solution to the problem. I'm against the policy change if at the same time Fedora package maintainers (of bitmap fonts, at least) do not seem to have a reasonable way to comply.

@adelton Fedora packaging guidelines document the way things are not the way you wish them to be (especially NOT the way you wish them to be in upstream code). Pango, and LibreOffice, and OpenJDK, and others have all migrated or are migrating to harfbuzz-ng, which is an OpenType-only solution (the solution agreed on upstream by Free Desktop apps a decade ago).

Fedora packaging guidelines should be clear on what the state of the art is for things to work in the distro, otherwise packagers expect it to be something else, complain loudly that this something else is not what they actually get, and that Fedora did not COMMUNICATE properly (as showcased in https://bugzilla.redhat.com/show_bug.cgi?id=1748495#c19 and https://bugzilla.redhat.com/show_bug.cgi?id=1753295#c57)

Encouraging people to package font files that won't work in all our major apps, and to hope that support for legacy formats will come back in some way, is not the way to get an healthy distribution.

And, BTW:

• I started working on this refresh a year before pango made its move,
• I had nothing to do with the upstream switchover date,
• but I am neither surprised nor unhappy the switchover happened in the meantime,
• it was a long time in coming,
• it was communicated in many ways for many years
• that pango did its move before my refresh was ready means people will spend less time shooting the messenger (me) instead of working on their OpenType migration strategy. So on the minus side I suck at updating guidelines timely but on the plus side I will get less abuse for documenting an unpleasant reality
• not that I don't expect a lot of people to blame me because they are not ready, people being what they are

Noone proposes to package fonts in formats that won't work in Fedora so you might want to stop repeating that rhetoric.

People would actually like to (help to) move to the new working state. So far however we don't know how and you haven't provided any technical guidance for Terminus, Lucida, or ucs-miscfixed-fonts. History and politics lessons won't fix those fonts.

I don't wish the policy to become the stick used against maintainers when they haven't been given the tools to actually be able to comply.

@adelton Fedora does not have a guidelines police. Maintainers of existing packages can and will lag on the state of the art, forcing them to do the right thing is asking for lots of abuse (so no one has the skin thickness to do guidelines policing at scale).

Guidelines document how things should be done for things to work right

They’re enforced on initial import, to avoid importing packages with a technical debt from day one

So guidelines will state that you MUST NOT package legacy font formats in Fedora, because they're not expected to work. And indeed they are NOT working right now, or in the foreseeable future, and it's not a bug, it's the result of a long-term dev roadmap (in Libre Office, in Pango, and in many others).

where's this macro coming from?

It's part of the fonts-rpm-macros set. I did not make the effort to push it in redhat-rpm-config because I only use it in font packages (but there, all the time)
https://pagure.io/fonts-rpm-macros/blob/master/f/rpm/macros.d/macros.fonts-rpm#_145

Also, it depends on uchardet for encoding detection and I didn’t want to expend the energy required to justify adding a new dep to redhat-rpm-config

The fontconfig side is in the same state as before (only better and more forcefully documented in the guidelines). The fontconfig templates in fonts-rpm-macros are byte-to-byte identical with the fontconfig templates in fontpackages. They are still limited to the patterns Behdad reviewed and approved in 2007.

I’ve started working on a newer and better fontconfig syntax here, taking into account what happened Fedora-side in the past decade
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/187
(plus all the following issues)

However, even assuming it gets instant buy-in by the fontconfig community once I finish describing it, it will take quite a long time to be implemented by someone, make its way into Fedora, and be available to write guidelines around.

And the fontconfig proposal is done:
https://lists.freedesktop.org/archives/fontconfig/2019-November/006626.html

We’ll see how people like @tagoh react to it.

I know it’s probably quite a lot of work, but the current state is pretty dismal, and I don’t think getting to the point where external engines try to second-guess fontconfig and pilot it via thousands of lines of generated config is something to strive for.

That would be recreating the sendmail mess, in xml, for a something which is a desktop subsystem.

AFAICT, kbd expects its fonts in /lib/kbd/consolefonts, not in /usr/share/consolefonts. Is this planned to move? Along with /lib/kbd/{consoletrans,keymaps,unimaps}?

AFAICT, kbd expects its fonts in /lib/kbd/consolefonts, not in /usr/share/consolefonts. Is this planned to move? Along with /lib/kbd/{consoletrans,keymaps,unimaps}?

/usr/share/consolefonts is more correct from an FHS POW, it is used and documented by other distros and exists in Fedora
https://koji.fedoraproject.org/koji/rpminfo?rpmID=18229681

Now, I haven’t checked if the result works, only that it already exists in the distro (if it does not work no idea which part of the distro is more at fault here, the ones using a clean common location, or the ones using an app-private working location).

The main point is to move those special format files in a special directory, outside the location for system fonts.

/lib/kbd/consolefonts has been outside the location for system fonts (/usr/share/fonts) for decades, so this has already achieved your goal to keep legacy font files outside /usr/share/fonts.

If you change the location of the console fonts to anything else but /lib/kbd/consolefonts, at least kbd utilities like setfont must work with the new location, dracut (for copying the necessary font files into the image) and its generated initrd image (to actually use the font files from the correct location in the initrd image) must also be made to work with that new location.

I have found three packages in Fedora 31 with dnf whatprovides /usr/share/consolefonts: cava, cmatrix, and console-setup (no idea how to find all packages which install anything anywhere within /lib/kbd or /usr/share/consolefonts).

As this time, the cava-0.6.1-4.fc31.x86_64 package cannot be used as a template for dealing with console fonts, as it does not work properly in many ways:

• cava calls setfont cava.psf to load cava.psf from setfont's default location which cava expects to be /usr/share/consolefonts where it installs cava.psf, but Fedora's setfont looks in/lib/kbd/consolefonts where cava.psf is to be found. So the console continues to use the default text font instead of the cava font.

• After it has finished, cava tries to set the console font back to a "normal" font by first calling setfont to restore some default 8xsomething font, then explicitly calling setfont /usr/share/consolefonts/Lat2-Fixed16.psf.gz which is not part of the cava package (it is part of the console-setup package, which the cava package does not require).

• cava does decidedly not restore the console font by having setfont cava.psf write the current font to a temporary file with something like -o or -O before it sets the font to cava.psf. If it did, it could restore that previous font without relying on any default or not even installed fonts.

Examining cmatrix-1.2a-5.fc31.x86_64 and its failures in the use of console fonts suggest it should not be taken as a model for functional and proper packaging either:

• The cmatrix package installs its font into /usr/share/consolefonts, while setfont later looks for the matrix font in its default directory /lib/kbd/consolefonts when called later, so the font is not changed at all. Symlinking or copying matrix.fnt and matrix.psf.gz from /usr/share/consolefonts to /lib/kbd/consolefonts fixes that.

• At least the cmatrix package has a wrapper script cmatrix-tty which tries to determine the font to restore after cmatrix has finished by trying to parse /etc/vconsole.conf, but it fails when the definition of FONT= in /etc/vconsole.conf contains a quoted string. Removing the quotes fixes the restoration part, at least iff the console font before starting cmatrix-tty happened to be the same one named in the FONT= definition of /etc/vconsole.conf.

I will not examine the console-setup package for its use of /usr/share/consolefonts in detail here. console-setup installs many dozens of *.psf.gz into /usr/share/consolefonts (including BTW what appears to be its local copy of an older version of Terminus), but console-setup appears to provide a complete infrastructure for setting up the console (as the package name suggests), so this might be a parallel system to kbd and its associated files. The console-setup README even mentions FreeBSD, so console-setup clearly appears to be a more cross platform package compared to Linux kbd.

Anyway, to summarize the above: In their current state, the three Fedora packages using /usr/share/consolefonts cannot be considered models for proper packaging or use of console fonts on Fedora.

If your goal is to unify the common parts of thekbd and console-setup infrastructure by having them use the same font and mapping files from /usr/share/consolefonts, you need to talk to people familiar with and maintainers ofkbd, console-setup, dracut, the startup process happening inside the initrd image, maybe anaconda, and possibly more parts of Fedora. No idea whether the benefits to Fedora are worth that effort.

However, for separating console fonts from the system fonts in /usr/share/fonts, it does not matter at all whether the console fonts are installed in /lib/kbd/consolefonts or /usr/share/consolefonts.

@ndim so /usr/share/consolefonts is present in Fedora, but in broken form.

Well I don’t care enough about console theming to spend energy on it. Switched to /lib/kbd/consolefonts

Anyone who fixes this mess has my blessing to update guidelines accordingly later.

@nim I might pick up changing Fedora to /usr/share/consolefonts for a F33 or F34 target, with FHS and inter-distro compatibility as goals.

I am not sure this is completely clear:

• [x] Font packages MUST contain font files in OpenType formats.

• [x] Other font formats MUST be converted to OpenType,
  except for fonts, intended to be used in the console (NOT a
  terminal emulator): see [Bitmap console fonts].

This makes it clear that having OpenType format fonts in a foo-fonts
package is mandatory, but does not say anything about whether
foo-fonts is still allowed to ship the original non-OpenType format
files in /usr/share/fonts/foo alongside the *.otb files, or maybe in
a separate /usr/share/fonts/foo-xft or /usr/share/fonts/foo-pcf
or similarly named directory.

Given that non-harfbuzz software (both in source and binary forms)
will be around for some time, I think Fedora must allow for either

• shipping the original non-OpenType format files in /usr/share/fonts/foo alongside the *.otb files

• at the very least allow for some compatibility packages for non-harfbuzz software in the form of some foo-fonts-compat-xft or similar subpackages with PCF or BDF or whatever those older formats are.

The foo-fonts-compat-xft option would require people to install extra packages if they use non-harfbuzz software.

Note: Console fonts

As long as kbd and systemd-vconsole can not use the same file formats
as the rest of the system, bitmap console fonts are effectively private kbd
resources. They will be ignored in the rest of this document. It does not
apply to them.

The following note does not explicitly mention other software using non-Wayland-X11-etc fonts, but the argument can be extended with analogues: For example terminus-fonts-grub2 ships additional fonts for grub2 in /usr/share/grub/ter-u*[bn].pf2.

Also in an analog way to the following rule, I have named that package terminus-fonts-grub2.

• [x] Bitmap console font packages SHOULD be named <something>-fonts-console not <something>-fonts.

Should I try to come up with an extended version of the above private resource note which covers both console fonts and grub2 fonts and maybe other uses?

I am not sure this is completely clear:

[x] Font packages MUST contain font files in OpenType formats.

[x] Other font formats MUST be converted to OpenType,
except for fonts, intended to be used in the console (NOT a
terminal emulator): see [Bitmap console fonts].

This makes it clear that having OpenType format fonts in a foo-fonts
package is mandatory, but does not say anything about whether
foo-fonts is still allowed to ship the original non-OpenType format
files in /usr/share/fonts/foo alongside the *.otb files, or maybe in
a separate /usr/share/fonts/foo-xft or /usr/share/fonts/foo-pcf
or similarly named directory.

The intent was to switch the whole system to openType only, but I see people really really want to read that they need not bother. Therefore I will add a

[x] Font packages MUST NOT contain non-OpenType font files

line. Aside from being a perfect waste of space, multi format packaging triggers subtle bugs in apps (in rendering, font lists, etc).

Given that non-harfbuzz software (both in source and binary forms)
will be around for some time

Harfbuzz is the core lib that deprecated legacy formats definitely. That does not mean new format support requires Harfbuzz use. Support for new formats was added to all kinds of libs a long time ago.

at the very least allow for some compatibility packages for non-harfbuzz software in the form of some foo-fonts-compat-xft

xft is a dead end. The previous (current) decade-old Fedora packaging guidelines already ask packagers not to add any font in the Fedora xfs store, and restrict it to the historical list of X11 core fonts. The people that continued to invest in xft despite upstream warnings and despite Fedora guidelines have dug themselves a hole. It’s not the guideline purpose to incite them dig it even further.

All of those people will deliberately take any opening in the guidelines as a Fedora endorsement of investing this dead end, and them flame us to us to a crisp when the dead end finally dead ends. I strongly advise against providing them any such opening. xft users have a migration to do since 2003. If they don’t want to invest in this migration and continue to live in denial, they can live with the font state of 2003 X11 (xorg core fonts). They have no business asking others to pour energy in keeping xft afloat just so they can procastinate some more.

@ndim

Note: Console fonts
As long as kbd and systemd-vconsole can not use the same file formats
as the rest of the system, bitmap console fonts are effectively private kbd
resources. They will be ignored in the rest of this document. It does not
apply to them.

Should I try to come up with an extended version of the above private resource note which covers both console fonts and grub2 fonts and maybe other uses?

Ideally, all this stuff should be converted to use of the common font store (with, perhaps, on the fly conversion of OpenType fonts to legacy formats as a stopgap measure.

However, if you want to take up guidelining for all those one-of-a-kind weird cases please please do it, you’re welcome (you may have noticed my own patience with those weird cases is running dry).

The main difficulty will be to find a packaging form, and document this packaging form, in a way that does not bleed nor drag down the rest of the system. People are quick to generalize deprecated tech exemptions into aligning the whole system system on deprecated tech assumptions.

Alright, after reading most of the new text, I'd say the new guidelines are quite comprehensive and well-written, and I don't see an issue that would block us from adopting them.

Some macro names are maybe unfortunate (some are combining both the plural -s and the -ex suffixes, which results in rather unfortunate combination) or look like AsciiSalad (in these cases, they could benefit from snake_casing) but I don't want to start bikeshedding exercises about this.

There are a few small typos and minor grammar issues in there, but nothing that affects the meaning of the text.

Some macro names are maybe unfortunate (some are combining both the plural -s and the -ex suffixes, which results in rather unfortunate combination) or look like AsciiSalad (in these cases, they could benefit from snake_casing) but I don't want to start bikeshedding exercises about this.

To clarify, I mean things like %{fontsex} (REALLY? is that supposed to be a joke?) or %{fontappstreamsex}.

Either it's an unfortunate combination of abbreviations, or an attempt at rather puerile humor. I'd prefer something like %{fonts_ex} and %{font_appstreams_ex} ...

@decathorpe Thanks for the review!

it’s just a combination of s (plural for all variables that contain lists of values) and ex (for exclusion).

I didn’t feel the unfortunate aspect was worth making the variable names longer and more annoying to type, especially since our guidelines still mandate 80 column limits in some places.

The go packaging guidelines FPC already approved use the same naming conventions (they also share quite a lot of macro code).

@nim right, that's what I thought. I won't block adoption of these guidelines based on that, but I still think it's rather unfortunate naming. :smile:

If that may feel you better the only exclusion variables which are likely to see common use are fontdocsex and (a lot less often) fontsex. The others have to exist as entry point (and be documented), but they’re not useful in the general case.

(needing to exclude appstream files is astronomically improbable as most upstreams, including the GNOME project itself, do not bother publishing appstream files for their font projects in the first place.)

Commit cb878dc4 fixes this pull-request