Talk:Font configuration

From ArchWiki
Jump to navigation Jump to 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)

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)

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)

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 ~~~~!

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: . 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, 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)

Disputable claims regarding DPI

I think the claims about DPI in is wrong.

First, 96 DPI is the de-facto standard of desktop GUIs, and altering it just puts application layouts in an inoptimal state.

And second, DPI has nearly nothing to do with distortion, apart from making the text larger or smaller.

So the DPI should be left at 96 and HiDPI scaling options should be used when the interface needs more zoom. Ishitatsuyuki (talk) 09:09, 25 October 2020 (UTC)