Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#52502 - [freetype2] Terminus font is not available

Attached to Project: Arch Linux
Opened by Dmytro Bagrii (dimich) - Wednesday, 11 January 2017, 23:29 GMT
Last edited by Jan Steffens (heftig) - Wednesday, 21 February 2018, 09:33 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Jan Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No

Details

Terminus font is not available.
All applications which use this font become to look ugly: rxvt-unicode, tilda etc.
Probably it happens after fontconfig and/or xorg-mkfontdir upgrade, but downgrading them to previous versions doesn't help.

Package versions:
terminus-font: 4.40-2
fontconfig: 2.12.1-4
xorg-mkfontdir: 1.0.7-5
This task depends upon

Closed by  Jan Steffens (heftig)
Wednesday, 21 February 2018, 09:33 GMT
Reason for closing:  Not a bug
Comment by Doug Newgard (Scimmia) - Wednesday, 11 January 2017, 23:55 GMT
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
Comment by Dmytro Bagrii (dimich) - Thursday, 12 January 2017, 00:09 GMT
Thank you! Workaround from that thread works for me.
Comment by Andreas Radke (AndyRTR) - Thursday, 12 January 2017, 13:15 GMT
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.
Comment by Doug Newgard (Scimmia) - Thursday, 12 January 2017, 14:07 GMT Comment by Andreas Radke (AndyRTR) - Thursday, 12 January 2017, 16:06 GMT
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.
Comment by Doug Newgard (Scimmia) - Thursday, 12 January 2017, 19:43 GMT
Check the commit I linked to
Comment by Jonny (dimman) - Thursday, 12 January 2017, 22:55 GMT
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.
Comment by Rodney Padgett (rp) - Thursday, 19 January 2017, 20:36 GMT
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!
Comment by Andreas Radke (AndyRTR) - Thursday, 19 January 2017, 21:07 GMT
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?
Comment by Jan Steffens (heftig) - Thursday, 19 January 2017, 21:31 GMT
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.
Comment by Rodney Padgett (rp) - Thursday, 19 January 2017, 21:39 GMT
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!
Comment by Vladimir Panteleev (CyberShadow) - Thursday, 20 July 2017, 07:14 GMT
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.
Comment by Vladimir Panteleev (CyberShadow) - Saturday, 12 August 2017, 07:27 GMT
> 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
Comment by Andreas Radke (AndyRTR) - Wednesday, 21 February 2018, 09:28 GMT
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.

Loading...