Arch Linux

No, this happened because of a change to freetype2, and has already been reverted upstream: http://lists.nongnu.org/archive/html/freetype/2017-01/msg00019.html

Thank you! Workaround from that thread works for me.

This is an intentional upstream change. You can easily configure your desktop/apps to make use of the new two word family names or add a font family matching rule.
I see no need to bring back the old unwanted behavior.

I'm even not sure if we should allow users to fall back and configure this at run time using
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=08fd250e1af0aa16d18012d39462e6ca9bbc6e90
Applying this single commit didn't make any change enabling/disabling pcf:no-long-family-names=1/0 for me. Maybe more commits are needed.

Upstream has already gone back to the old behavior: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7ccca6aec167c2c30c569765ece808f0eee023a6

No. They only implemented the option to revert that change at runtime. Read the comment inside that patch. That commit just enable the variable reading. It doesn't set it back by default.

Check the commit I linked to

Reading through the mailing list of freetype2; yes this "feature" causing this bug is now OFF by default.
Next release will fix the issue.

Note to maintainers here: I would take an extra look at freetype2 releases in the future, upstream has made
it clear that their way of looking at version numbers does _not_ include effects for end users (I had a discussion
with Werner from freetype2).

A quote snippet from Werner: "[...] since
FreeType uses libtool, it [the version number] relates to DLL versions and *not* to the
tarball versions."

I personally strongly disagree with their way of versioning as I think it's very wrong and makes it hard for
users/distro maintainers to know when its safe and when its not safe to include a new package version.

The issue is really with the terminus font package: it installs the file /etc/fonts/conf.avail/75-yes-terminus.conf. If you have bitmap fonts disabled (70-no-bitmaps.conf) 75-yes-terminus.conf will not enable terminus because it hasn't been updated:

<patelt name="family"><string>Terminus</string></patelt>

needs updating to

<patelt name="family"><string>xos4 Terminus</string></patelt>

I reported this upstream, but I guess it's not going to change anytime soon as each distro can now choose whether to enable this 'feature' or not!

Why don't you just use the proper two word font family name in your font settings?

I changed it here from
URxvt*font: xft:Fixed:pixelsize=12
to
URxvt*font: xft:Misc Fixed:pixelsize=12

Arch follows upstream - that's our rule. Why not here?

We're already in the situation that user configs need to adapt to the current FreeType behavior.

I think that the most pressing issue is that users will need to revert their changes when the next FreeType release disables the long family names again.

We should ask upstream whether the setting will be on by default in some future release. If so, we should keep it on by default until then with a downstream patch. That way users won't have to adapt their configuration thrice.

Those look like .Xresources settings to me? But not everything uses .Xresources - your method works well for packages which use .Xresources, e.g. xterm and xmessage I have configured this way.

Sorry I wasn't clear I meant I reported it upstream to the terminus developer (since 75-yes-terminus.conf is part of terminus package) - but since each linux distro can choose whether to enable fontconfigs new naming scheme or not it's unlikely he will change the file, especially now that fontconfig is going to default to the old behaviour as stated above. I agree completely with the philosophy of following upstream!

Hi, I posted  FS#54866  yesterday which has been closed as a duplicate of this issue. (I'm not sure if it can be truly considered a duplicate, as it is a different problem with different symptoms, workarounds, and affecting different code paths, just brought on by the same change. JGC hasn't replied to my question about this.) Anyway, I'll repost it here so it doesn't get lost:

-----

Hello,

I noticed that 0004-Enable-long-PCF-family-names.patch is breaking certain programs under certain conditions. Specifically, it becomes impossible to select certain fonts from the Fixed family with the patch applied.

Steps to reproduce:

1. Open Kolourpaint
2. Select the text tool, and add some text to the canvas.
3. Select the "Fixed" font family. Without the patch, it will be listed as "Fixed [Misc]". With the patch, it will be listed as "Misc Fixed".
4. Select size 10.

Expected result:

https://dump.thecybershadow.net/5996b3b2c59570d76944c92297e7fa7e/02%3A58%3A35-upload.png

Actual result:

https://dump.thecybershadow.net/2ae508861ded4f33bc440f3fff935474/03%3A00%3A57-upload.png

Also note that no matter which settings are chosen, it is no longer possible to select the exact font as shown in the "Expected" screenshot.

As such, please consider dropping the patch.

> Applying this single commit didn't make any change enabling/disabling pcf:no-long-family-names=1/0 for me. Maybe more commits are needed.

Finally figured out why this doesn't work.

Make sure the environment variable is set at fc-cache execution time. For example:

sudo sh -c 'FREETYPE_PROPERTIES="pcf:no-long-family-names=1" fc-cache -rvf' ; FREETYPE_PROPERTIES="pcf:no-long-family-names=1" fc-cache -rvf

Jan, any further comment on this? I guess we can close this "not a bug". We had several updates since that days. All users should have adopted new behavior.