Talk:Font configuration

From ArchWiki
Jump to: navigation, search

Unclear instructions

It is not entierly clear what file the following configuration should be put:

Keep in mind that Xorg does not search recursively through the /usr/share/fonts/ directory like Fontconfig does. To add a path, the full path must be used:

Section "Files"
    FontPath     "/usr/share/fonts/local/"

axper (talk) 08:43, 30 November 2013 (UTC)

freetype2 config changes

freetype2 no longer uses local.conf (same with infinality) and has switched to /etc/fonts/conf.d/* config files symlinked to /etc/fonts/conf.avail/*. I'm happy to update this page but don't want to step on the plans of someone more informed than I. If I don't hear back in a week or so I'll go ahead and add some minor changes to reflect this new configuration setup.

Freetype2 has had conf.avail and conf.d for a while. One of the files in conf.d is "51-local.conf" and that lets you use /etc/fonts/local.conf for your own local settings. The freetype2-infinality package just now installs the default non-customized Infinality config to conf.avail so people know it exists without reading the documentation. thestinger 13:18, 30 November 2011 (EST)

Contradictory recommendations?

I'm not familiar with fontconfig - I've configured it rarely and a long time ago for a different OS. So I'm not sure if something is just not clear to me but as I read the article, it is giving me contradictory instructions:

  • early on, it suggests enabling both the autohinter and subpixel rendering to improve appearance after installing msfonts
  • later on, it says that the autohinter should not be used with subpixel rendering

I realise that the methods used to enable these are different in the two cases (one sets up symlinks in conf.d; one adds sections to local.conf) but if this explains the apparent inconsistency, it would be really good to explain why there's no conflict in this case. --Margali 19:07, 4 March 2012 (EST)

Autogenerating missing shapes and weights

Since the article is about improving the appearance of fonts, I would suggest qualifying the section which explains how to have fontconfig generate italics and bold/bolder fonts on the fly. I doubt very much that it is faking italics. I assume it fakes slanted versions (which are not the same as italics). Moreover, it is unlikely that the results of autogeneration will be especially pleasing. Font designers would abhor such things and not, I think, because they need the work! Faked versions can be acceptable but they will not look as good - the spacing will not be optimal, the shapes of the glyphs and the metrics will not be quite right as good fonts vary these things appropriately for different weights, shapes and sizes. --Margali 19:13, 4 March 2012 (EST)

Configuration confusion

As currently set out, I'm not clear what the relationship is between configuration via symlinks in conf.d (adding to conf.avail as needed) and via local.conf. Should these be used for different aspects of configuration? Or are they equivalent/interchangeable?

I also don't quite understand about the numbering. It looked to me as if higher numbered files under conf.d were more specific than lower numbered ones. I assumed this was so that e.g. config specific to a particular font overrode general, default config for all fonts. But the article suggests that is wrong. So should I be renumbering the files there in order to get this behaviour?

e.g. Will the font-specific set up in 20-unhint-small-dejavu-sans-mono.conf get overridden by 10-bcihint.conf (a file I created with the section for BCI hints from the article)? I used 10- because that's the number for the autohinter file under conf.avail so I assumed that number was about right.

--Margali 19:23, 4 March 2012 (EST)

October 2013 Quality of Font Rendering

The package extra/fontconfig was updated to 2.11.0-1 as at 2013-10-13 (UTC). Per [BBS#1337337] by anton and associated ArchLinux flyspray entry [FS#25499], the file 29-replace-bitmap-fonts.conf was dropped from the package (this file was an ArchLinux customisation).

anton provides a workaround in that thread, as does FDServices at [BBS#1337433] and heftig at [BBS#1337776]. I can confirm -- at least on my rig -- that the workaround provided by FDServices was successful after log out/in to establish a new session

I am noting this here for the benefit of other contributors who may come hunting for this over time; not sure if (or how) it should be worked into the main article. Full credit is due to the contributors named above for this, rather than me; I am merely the messenger here!

--aexoxea (talk) 14:46, 15 October 2013 (UTC)

Further to the above, here is a 'compromise' method (per the information provided by FDServices and heftig above) that doesn't involve restoring the 29-replace-bitmap-fonts.conf file, and that seems to be working OK here: Install extra/tex-gyre-fonts and then symlink /etc/fonts/conf.avail/70-no-bitmaps.conf under ~/.fonts.conf.d/.
Obviously this is user-specific, but it also avoids creating the symlink under /etc manually (since files created therein other than by packages tend to be forgotten). As I know comparitively little about font configuration, any feedback on issues or potential issues with this method is welcomed.
--aexoxea (talk) 07:08, 16 October 2013 (UTC)
The above generated some warnings for me, so I'm now using destination directory ~/.config/fontconfig/conf.d/. This appears to be an XDG-preferred destination (at least on ArchLinux), however I don't know whether others mileage may vary, so both are noted here. Hopefully the last update to this thread from me!
--aexoxea (talk) 08:14, 18 October 2013 (UTC)

Change Rule Overriding

I'm fairly sure that this section is completely incorrect. I believe that while fontconfig does scan the XML files in the order stated, the first file scanned has the highest precedence. Hence 99-user.conf actually has the minimum precedence, and would therefore be overridden by anything else. --Teppic74 (talk) 19:26, 6 June 2014 (UTC)

Now it should be correct. --Larpico (talk) 03:41, 28 October 2014 (UTC)
My edit was reverted, but that's fine because it was incorrect. Unfortunately, the information that replaced it, is also wrong. Rule overriding in fontconfig seems to be quite complex. alexoj provides a very good explanation in this issue. --Larpico (talk) 23:04, 3 July 2015 (UTC)

Font Configuration - fontconfig-good-defaults

[Moved from User talk:Lahwaacz -- Alad (talk) 00:27, 13 October 2015 (UTC)]

Hello, you recently removed the section on fontconfig-good-defaultsAUR from the wiki and flagged for deletion it on the AUR.

>There are much better ways to share *your* personal configs. If something is missing on this page, add it and *explain* what it does.

Then let me explain. This package enables a variety of settings that would be the upstream default for all of FreeType and Fontconfig if it were not for a massive number of United States patents on font rendering. (See You seem to be implying that these settings are not suitable for other people's systems and that it only changes the configuration to my personal preferences, which is not the case.

It is very similar to the Infinality and Ubuntu patchset, although it does not require patching FreeType and Fontconfig because Arch Linux already does this. However, Arch Linux does not enable the patent encumbered settings by default. Seeing as most people do not live in the United States, do not want to have to patch packages, and do not want to understand the intricacies of Fontconfig XML configuration and FreeType patching to get decent fonts, I made this into an easy to install package.

I do agree that the wiki needs a section on enabling the Arch Linux patches. However, it is wrong to remove fontconfig-good-defaults from the wiki or the AUR. It is essentially Infinality, but much simpler and in vast majority of cases does not require any additional changes after installing. In fact, most of the configuration that it enables has already been on the wiki for years as the recommended example fontconfig configuration.

If I elaborated on this in the section, would you be willing to it allow back on the wiki? If so, I will also write a separate section on enabling the Arch Linux patches.

Even if you disagree about it being on the wiki, flagging it for deletion on the AUR was completely wrong. This package in no way violates the rules of submission for the AUR. (See Can you please revoke the deletion request?

The reason I put this on the AUR was to make it easy to enable settings that should be the default. You claim to know of better ways to share this configuration; can you please explain these to me? Using the AUR seemed like the best solution as it allows for easy installation and maintenance updates.

I appreciate you taking the time to read this. Please address the AUR request in a timely manner.

Sushi Dude (talk) 11:12, 21 September 2015 (UTC)

One thing I don't comprehend is how implementing a feature in some FOSS project can be in compliance with the patent rules, but enabling it by default noncompliant.
But this is not about patents, licenses or rules of submission for the AUR (except that it says to "Make sure the package is useful"). This is about how Arch distributes configuration files. Leaving aside extensive patchsets, there is always one set of configuration files distributed as part of the package, with defaults taken usually directly from upstream. Any customizations are to be applied by the end users, who are responsible for the configuration of their system, not by packagers. Providing modified configuration files as packages effectively prevents other customizations (i.e. why would you modify a modified configuration?). Have you seen any configuration-only packages in the official repositories or even the AUR?
As for the Arch wiki, its purpose is to provide a manual for the customizations, not ready-made configuration file sets without any description or explanation why the changes were made. One way of sharing personal configuration is described in Dotfiles.
Edit: it is not possible for me to withdraw the deletion request, it will have to be accepted or rejected by a TU.
-- Lahwaacz (talk) 12:37, 21 September 2015 (UTC)
>One thing I don't comprehend is how implementing a feature in some FOSS project can be in compliance with the patent rules, but enabling it by default noncompliant.
You and me both.
>Providing modified configuration files as packages effectively prevents other customizations
I specifically made the package such that it will not overwrite any settings set by the users.
>Have you seen any configuration-only packages in the official repositories or even the AUR?
Yes, actually. Off the top of my head I can think of grml-zsh-config in extra and zsh-syntax-highlighting in community.
>As for the Arch wiki, its purpose is to provide a manual for the customizations, not ready-made configuration file sets without any description or explanation why the changes were made.
I do not understand why the Infinality and Ubuntu patchsets are an exception to this rule.
I am trying to simplify the need for configuring fonts in the first place. Considering how most people use that wiki page solely to enable features that are disabled because of patents.
Sushi Dude (talk) 13:16, 21 September 2015 (UTC)
zsh-syntax-highlighting provides an "extension" for the basic shell and has to be enabled and configured manually. But you got me on grml-zsh-config, one reason for it being an official package is its presence on the installation image.
Why do you think that Infinality has special treatment on ArchWiki?
-- Lahwaacz (talk) 14:27, 21 September 2015 (UTC)
Some follow up edits: [1] [2] [3] [4]
Re Ubuntu, if we can't document this properly, I'd argue in removing the package links from the wiki.
As to Infinality, it isn't special per se, but bohoomil's configuration is: from Infinality#Installation_2:
Infinality-bundle is a collection of software providing an easy, "install-and-forget" method of improving text rendering in Arch Linux.
-- Alad (talk) 15:40, 21 September 2015 (UTC)
The request was accepted [5], but the other points remain, so I'll leave this open for now. -- Alad (talk) 00:29, 13 October 2015 (UTC)
In response to the request being accepted see:
Sushi Dude (talk) 06:27, 17 October 2015 (UTC)
Looks like this is final, closing. -- Alad (talk) 19:41, 9 August 2016 (UTC)

Font configuration#Font problem in Generated PDFs states gsfonts (Type 1)

Font configuration#Font problem in Generated PDFs, which is section 4.6 in Font configuration#Troubleshooting, states gsfonts (Type 1). Doesn't gsfonts-20160531 OTF, while 2015 and earlier, were Type1? While at it, perhaps xorg-fonts-type1 should be mentioned too. —This unsigned comment is by Regid (talk) 14:56, 2017 March 16. Please sign your posts with ~~~~!