Obsolete yet?

[alerque]

Given that fontconfig itself has changed significantly since the infinality patches started being a thing and that other parts of the stack have changed (e.g. the dropping of full hinting support in Pango), how relevant is it to keep maintaining this? What is actually useful now?

I ask as someone who maintains a bunch of AUR font packages with infinality configs included. Feedback on whether to continue that effort or remove them from the AUR would be appreciated: https://github.com/alerque/aur/issues/8

[pdeljanov]

This is a tough question. It's also rather subjective. In my opinion, on low DPI screens, Infinality is absolutely an improvement. I wouldn't like using Linux without it.

However, the bad news is that it's becoming harder and harder to port the patches to newer versions of FreeType. I basically copy large portions of old Infinality code into new FreeType and then try to massage the bits that don't match anymore to compile. Unfortunately, I have no domain knowledge when it comes font rendering or FreeType itself so if it works (or breaks other things) is down to luck.

Personally, I've since moved on to high DPI screens and have stopped using Infinality patched FreeType and Cairo libraries. I do still use the patched FontConfig library for the font substitutions (there are actually no code changes to FontConfig, just added .conf files).

Going forward I think it is unlikely I'll be porting Infinality to newer FreeType versions. However, when I have time, I do plan to introduce a new package containing just the font substitutions that can be used with the official FontConfig build.

As for whether or not you should maintain font packages with included Infinality configs? I don't personally think they're necessary even with Infinality. In my experience fonts without Infinality configs looked fine.

Hope I've provided you some clarity and thanks for asking the question. I've been thinking about the future of Infinality too.

[alerque]

Thanks, that does help clarify the situation a bit.

Do you know if this is the only working infinality patched freetype / fontconfig effort being used on Arch Linux or are there others?

[pdeljanov]

freetype2-infinality-remix was for a while the only Infinality-patched version of freetype 2.10.1. Now it looks like freetype2-infinality and lib32-freetype2-infinality-ultimate from the AUR have both adopted the patch from this repo.

As far as I can tell there are no other Infinality branded freetype packages. There are also no AUR fontconfig packages that use the fontconfig patches from this repo. That makes sense though, I've only added in a new "remix" preset so I wouldn't expect any other package to use it.

So I guess the only question is if either the maintainer of freetype2-infinality or lib32-freetype2-infinality-ultimate wants to take responsibility for porting the patches to newer versions of freetype.

[xalt7x]

It's also used by some Ubuntu users https://github.com/achaphiv/ppa-fonts https://launchpad.net/~no1wantdthisname/+archive/ubuntu/ppa I use that PPA and see improvement on FullHD screen. Also patched ibfreetype.so.6 fixes font rendering for at least one abandoned GTK application ( https://github.com/buglloc/brick ) on KDE Plasma (actually you don't have to replace system library, just drop into app folder). Apart from that, after upstream merged some infinality code and distribution started to compile with appropriate flag, situation got a lot better, especially for non-Ubuntu-based distros. But I think that config modding is a good area to explore. Ubuntu, MX Linux, cryzed, infinality maintainers got pretty impressive results. Especially interesting fontconfig-infinality - 20130104-0ubuntu0ppa1 which simulates different types of rendering (Windows XP, Windows 7, OSX). The problem is that all those packages/repos are pretty chaotic or contain too much bloat and not universal across distributions (some configs are duplicated on distro, some fonts are not packaged or outdated etc). I would like to have some modern lite version with different options like fontconfig-infinality - 20130104.

[ajP89]

Sad to hear. I have 720p screen and the 3 remix packages really make fonts look clear and crisp.

[alerque]

@ajP89 Are any of the Arch *-ib/*-ibx/*-infinality packages part of your mix or are just the patched fontconfig etc. enough to get what you consider to be improved results?

[ajP89]

@alerque I've only installed the 3 packages. They are enough in my opinion. I have also used fontconfig settings in etc/fonts/local.conf, which improve fonts, but not by much. I read a lot on the laptop so font rendering is very imp for me. I found this package while searching around 6 months back and fonts have never looked better on linux for me. And I don't think it can get any better than this. Thanks @pdeljanov.

[pdeljanov]

I've ported the patches to 2.10.4, but unfortunately it crashes at runtime. More details are in #15. If this can't be fixed relatively easily then the future of Infinality looks bleak. If someone with more domain knowledge can take a look it'd be great!

[sindex]

This is a tough question. It's also rather subjective. In my opinion, on low DPI screens, Infinality is absolutely an improvement. I wouldn't like using Linux without it.

However, the bad news is that it's becoming harder and harder to port the patches to newer versions of FreeType. I basically copy large portions of old Infinality code into new FreeType and then try to massage the bits that don't match anymore to compile. Unfortunately, I have no domain knowledge when it comes font rendering or FreeType itself so if it works (or breaks other things) is down to luck.

Personally, I've since moved on to high DPI screens and have stopped using Infinality patched FreeType and Cairo libraries. I do still use the patched FontConfig library for the font substitutions (there are actually no code changes to FontConfig, just added .conf files).

Going forward I think it is unlikely I'll be porting Infinality to newer FreeType versions. However, when I have time, I do plan to introduce a new package containing just the font substitutions that can be used with the official FontConfig build.

As for whether or not you should maintain font packages with included Infinality configs? I don't personally think they're necessary even with Infinality. In my experience fonts without Infinality configs looked fine.

Hope I've provided you some clarity and thanks for asking the question. I've been thinking about the future of Infinality too.

My usecase is the exact opposite. I use the stock fontconfig cause I don't care about font substitutions except using the Courier font from Bitstream (the stock Courier New clone is ugly) and rules for emojis. In Low-DPI monitors, I use stock everything but in HiDPI even with no hinting everything looks extremely thin and I find it tiring and ugly. The values for gamma, e.t.c., I use are still not as extreme as MacOS but very different to stock.

[CapSel]

Next best thing - Ideas for workaround with current software available to us

It is possible to enable "infinality" mode in freetype provided by Archlinux. What this is may not be what you want but you could just try.

File /etc/profile.d/freetype2.sh has an example of environment variable that should be set. There is an example of three modes:

# Subpixel hinting mode can be chosen by setting the right TrueType interpreter
# version. The available settings are:
#
#     truetype:interpreter-version=35  # Classic mode (default in 2.6)
#     truetype:interpreter-version=38  # Infinality mode
#     truetype:interpreter-version=40  # Minimal mode (default in 2.7)
#
# There are more properties that can be set, separated by whitespace. Please
# refer to the FreeType documentation for details.

To enable "infinality" mode place this line

export FREETYPE_PROPERTIES="truetype:interpreter-version=38"

To apply changes you need to at least relogin. Reboot might be good idea.

Rest of configuration can be performed by creating/removing links in /etc/fonts/conf.d/ or/and in file ~/.config/fontconfig/fonts.conf. You should also put same configuration in ~/.Xresources. Examples are here https://wiki.archlinux.org/title/Font_configuration After these changes a program that you test your fonts with should be restarted. Relogin or reboot also help here.

So:

• for MacOS like font rendering you should disable font hinting (not antialiasing). Fonts would be less crisp. This tends to look better on HiDPI screens.
• for Windows like font rendering (crisp) can be achieved by setting hinting to medium
• traditional Linux font rendering is achieved by setting hinting to slight
• setting autohint for me kind of looks like if letters are not where they suppose to be.
• for HiDPI LED wayland (gnome) display I can't see differences between enabling and disabling hinting
• on HiDPI displays and with 1.5 scaling fonts in some apps looks diluted
• LCD filter should be enabled. I've read that legacy mode is deprecated and may not work anymore. On one of my computers/displays lcddefault looks better, lcdlight on the other.
• there is only one set of rendering settings for entire system - you can't have different set for different displays
• I always enable antialiasing and correct rgba mode - all my displays use rgb

Last thing - even setting FREETYPE_PROPERTIES to newest mode - the "default" value of 40 - kind of fixes some minor issues with font rendering even without other changes... or I just stared at my fonts for too long and got used to ;)

If you have any more ideas, explanations, or you disagree with me on any point post them here.

[RJVB]

If someone with more domain knowledge can take a look it'd be great!

4 years later and I can still not find any easily-uncovered trace of there being newer versions of the patches, and they really do still make a night-and-day difference on normal-resolution displays.

OTOH, I find that I can still use FreeType 2.8.1 for pretty much everything and for now have only encountered applications that claim to need a newer version.

Of course that doesn't help with applications built against a newer version of the library, as is more and more likely to happen on distros with binary packages... :(