[Fontconfig] Some things should not be configured through files like fonts.conf

[Wolfgang Draxinger]

So here's the problem:

Consider a workplace with several computers with different physical
configurations (example in case: my workplace):

The software development workstation "hilbert" on my desk is a
multi-head setup with 2 monitors. Those are in portrait rotation mode,
to maximize vertical space, since this is a coding workplace. The
subpixel alignment as the user looks onto is vBGR (relative to the
wooden desk). My peers have personal workstations as well.

The system "maxwell" at the electronics workbench (shared by all
people in the group) is a dual screen setup as well, however one is a
landscape 24" screen (hRGB relative to the desk) and the other screen
is a pivotable 17" screen some people prefer to use in landscape and
others prefer to use in portrait mode.

In the laser lab a whole bunch of machines "${EXPERIMENT}.lab...", most
of them diskless thin clients and an assortment of old monitors that
accumulated over the years are available from the shelf for experimental
setups. Since experiments tend to run for prolonged periods of time its
customary to let them run unattended and from time to time open a
remote connection (usually X over SSH) to check on the system status.
Those machines usually run in a single head, or even headless setup;
most of the monitors have an hRGB layout, some however are hBGR.

All these machines mount their /home from a central file server.

And that's where the trouble starts. Say I prefer RGB subpixel
antialiased, fully hinted glyph rasterization. Some of my peers however
prefer grayscale antialiased, unhinted and other peers want
unantialiased font rendering. This shared setup means, that we can not
configure rasterization options globally on each machine. The pivotable
screen at "maxwell" also disallows to configure a global subpixel
layout.

So since these configurations are strictly per user, all font
rasterization configuration happens through the configuration files in
the user home directories.

However, because the home directories reside on a central file server,
all machines see the same fontconfig configuration. However since the
screen setups are so different, it's impossible to cover them all in a
single configuration.

Okay, so you look at the fonts.conf manpage and see, that there are
environment variables you can use to point to default configuration. So
you set those variables in ~/.profile to point at a custom base
configuration specific to each host. Unfortunately switching that base
configuration makes the whole fonts.conf incredibly convoluted; adding
the fact that diskless stations are allocated dynamically by experiment
name clutters the configuration directory.

Even worse: Some people might want to pivot the screen at "maxwell"
while being logged in, requiring a change in configuration and often a
session restart then.

So assume you've got the configuration somehow managed based on the
host you're running the programs on. You have that and then you do
`ssh -X` or `vncviewer` (starting on demand an X session) AND
EVERYTHING BREAKS, because now the programs are doing their glyph
rendering based on the configuration of the host they're running on,
but the display output happens somewhere else with a completely
different physical setup.

The above setup is a reality for me and the quite unsatisfying
"solution" is to either disable antialiasing on all machines or use
grayscale everywhere.

For some time you could use the X resource database to configure the
font rasterization options; but AFAIK those have been removed. At least
the entries I have in my ~/.Xresources no longer have a noticeable
effect. Which is a pitty, because they configure properties of the root
window when doing X over SSH (or even plain tcp, but who uses that? ^2)
it took care of mediating the proper configuration to remotely executed
programs. Also merging the relevant entries into the Xrdb is much
easier than to juggle around with a plethora of symlinks and
dynamically created fonts.conf files; it boiled down to a

xrdb -merge < .Xresources.xft.${HOST}

Still this is not optimal though. Let's forget about the structural
problems involved if you have a multi-head setup with different
subpixel arrangements for each screen for a moment (^1) or just think
of a tablet computer where the screen orientation is changed by the
natural user interaction of rotating the device.

You've got to admit that there are certain aspects in glyph rendering
which are highly dynamic and are difficult to map in a static
configuration scheme based on files-in-storage. Honestly I was already
considering to write a FUSE filesystem that would dynamically create a
fonts.conf.d to mount; but that would just be another crude layer of
plaster over the cracks.

This is an ongoing issue that now bugs me for years. But the past few
days I got into an Internet argument (*sigh* yeh, I know, don't feed the
trolls) about the woes of font configuration. My stance on that is,
that computers and software are there to alleviate the user from
repetetive tasks. Things like display configuration and the finer
details of glyph rendering should not be something that is to be
configured at all: The system shall determine the parameters at runtime
from the properties of the connected devices; its perfectly valid to
have some daemon program to keep track of these settings and place them
in a display wide configuration. However since displays may be
associated with sessions of a user who is logged into multiple machines
at once it makes absolutely no sense to store this configuration in a
file of the user's profile. This is something that should be kept track
in the display server.

So can somebody please give only one valid argument, why you want to
place the configuration of the subpixel arrangement and antialiasing
mode in a system-wide and/or per-user configuration, when it in fact
depends most on the physical screen setup the rendering result will be
visible on?


Greetings

Wolfgang

[1] Neither X11 nor Wayland can effectively deal with this. And lets
assume a toolkit actually manages to take into account screen viewport
borders, window overlap and so on. Switch on Clone Mode and you're SOL,
again.

[2] Oh yeah, we do on some of the machines in the lab's network