Talk:Font configuration

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/"
EndSection

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

I believe axper refers to Font_configuration#Font paths.

I have just added a reference to Xorg#Configuration there.

Regid (talk) 20:07, 31 March 2021 (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.

—This unsigned comment is by Altercation (talk) 18:10, 30 November 2011‎ (UTC). Please sign your posts with ~~~~!

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)

only convenience, you could use cat to concatenate them into fonts.conf and it will work, fonts-conf(5) has some information, not sure about the numbering ―Ubone (talk) 03:10, 16 September 2018 (UTC)

Does #Rule priority, which is from 2022, has basically the same question about the numbering? Regid (talk) 17:24, 23 December 2022 (UTC)

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)

Helvetica, and the solution to install tex-gyre-fonts, are also mentioned at 4.7 Helvetica font problem in generated PDFs. Are these 2 issues related? Regid (talk) 17:41, 23 December 2022 (UTC)

Subpixel rendering

My edit on subpixel rendering for freetype2 just got reverted. To elaborate further: What's needed in order for the lcdfilter options to take effect is the FT_CONFIG_OPTION_SUBPIXEL_RENDERING, see [1]. This is *NOT* the same as TT_CONFIG_OPTION_SUBPIXEL_HINTING, which is enabled in Archlinux. Debian and Ubuntu enable SUBPIXEL_RENDERING in their binary packages, Archlinux doesn't. —This unsigned comment is by Iridium (talk) 21:23, 11 February 2018‎. Please sign your posts with ~~~~!

What's the difference between subpixel rendering and hinting? The claim that the instructions don't make any difference is not correct due to the note on subpixel hinting. In any case, the section should be reworked instead of adding a warning that the following instructions don't make sense. -- Lahwaacz (talk) 17:17, 12 February 2018 (UTC)

Hinting is the process of aligning the font to the pixel grid in such a way that you maximize the sharpness while reducing the accurecy of spacing between letters a bit. freetype has done hinting for ages, either automatically (autohinter) or by interpreting bytecode embedded into truetype-fonts (although that has been disabled for some time due to patent issues). Subpixel rendering is the process of rendering letters in such a way that you exploit the physical LCD layout and the fact that the human eye is more sensitive to brightness than to color. Effectively, the vertical (or horizontal) resolution of the font rendering grid is tripled and the glyph is then rendered as usual, ignoring the fact that the subpixels have different colors. Example image: https://upload.wikimedia.org/wikipedia/commons/5/57/Subpixel-rendering-RGB.png . Subpixel hinting extends the hinter to align the glyphs on the grid defined by the subpixels (not pixels) on the screen, which obviously becomes useful once you render on the grid defined by the subpixels. Once you enable subpixel rendering, you get slight color fringes at the edges of the glyphs. The lcdfilter-option applies a low-pass filter to the resulting image to reduce the visual effect of these, while slightly reducing sharpness. Archlinux enables subpixel hinting, but not subpixel rendering. However, without subpixel rendering, subpixel hinting does not make much sense, as the rendering engine is going to output only pixels with R=G=B anyway. Still, the truetype-interpreter-option seems to make a slight difference, as it generally gives slightly different hinting results. Still, without subpixel rendering, the hinting-part does not make much sense. The lcdfilter-option is ignored alltogether (see https://www.freetype.org/freetype2/docs/reference/ft2-lcd_filtering.html), as in the absence of subpixel-rendered fonts, low-pass-filtering does not make any sense. After having a quick look at the freetype-source, the rgba-option at least has some effect: There is a difference between verical and horizontal subpixel-alignments, even with disabled subpixel-rendering. Still, enabling this option on an archlinux-system using distribution package won't have the described effects. Iridium (talk) 12:51, 25 February 2018 (UTC)

Rule priority

I don't really understand the behavior described in this article. #Rule priority says:

the fontconfig syntax is flexible and allows that a new rule takes precedence over an existing rule

which means that files starting with a higher number will take precedence.

However, the same section describes the exact opposite behavior:

... 50-user.conf ... typically take precedence over the rules defined in files starting with a higher number.

And #Fontconfig configuration says:

The settings in the per-user configuration have precedence over the global configuration.

Well, I tried to do some experiments to see which file would actually take precedence.

Experiment 1:

/etc/fonts/conf.d/49-test.conf

<match target="font"><edit name="antialias" mode="assign"><bool>false</bool></edit></match>

Antialiasing is disabled, there are no files that can overwrite this configuration.

Experiment 2:

~/.config/fontconfig/fonts.conf

<match target="font"><edit name="antialias" mode="assign"><bool>true</bool></edit></match>

Antialiasing is enabled, 50-user.conf takes precedence over 49-test.conf.

Experiment 3:

# mv /etc/fonts/conf.d/49-test.conf /etc/fonts/conf.d/51-test.conf

Antialiasing is disabled, 51-test.conf takes precedence over 50-user.conf.

Experiment 4:

# mv /etc/fonts/conf.d/51-test.conf /etc/fonts/local.conf

Antialiasing is disabled, the global configuration (51-local.conf) has precedence over the per-user configuration.

Experiment 5:

# rm /etc/fonts/local.conf

Antialiasing is enabled, there are no more files that can overwrite antialias.

Does this mean that the article has incorrect information about "the per-user configuration have precedence"?

I'm not a fontconfig expert and might have made some mistakes, so I'm not going to edit the article myself, but I'm asking someone to update the article to describe the correct and consistent information.

andreymal (talk) 15:05, 27 March 2022 (UTC)

Disabling embedded bitmaps breaks emoji fonts

This was a rather puzzling issue - and i have a very minimal fonts.conf to boot - till i found this FF bug report where last comment finally made sense: most popular emoji fonts use bitmaps after all.

Removing the snippet from my fonts.conf unbricked emojis in Firefox's ui (i.e. search/url bar for example) and Gajim's emoji picker where they were totally broken before.

I suggest placing a warning in that section that disabling bitmap fonts globally is not without drawbacks and probably should not be done blindly those days, lest someone wants to live with 0 emojis in their system. Bugmenot3 (talk) 17:37, 29 March 2023 (UTC)