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

[Wolfgang Draxinger]

On 04/07/14 11:06, Akira TAGOH wrote:

> 1. we don't want to make X dependency in fontconfig because it's not
> necessarily required in other platforms.

Well, look at it like the dependencies for toolkits like Qt or GTK+. X11 
is not a hard dependency for those either, but a compile time option. 
Heck you could make this a link time option for programs that use 
fontconfig. So you'd have a base fontconfig library, that cares about 
the static aspects of font selection, glyph replacement, etc. And in 
addition to that you'd have dynamic configuration providers you simply 
link alongside.

And for things like e.g. Xft (which has a hard dependency on fontconfig) 
you have X11 has a hard dependency anyway.

> 2. is there any database contains sub-pixel layout information?

Not yet. At least no FOSS one. Windows and MacOS X actually have such 
databases to work around buggy EDID data (ever installed a monitor 
"driver" in Windows? That .inf file contains records for that database).

Such a database is not hard to maintain. Heck I volunteer to do this. 
The really hard work is having people look at their monitors and 
determine the relevant values.

 > who manages?

As of now, I do.

> 3. even if it's going to live, how does it help for the preference
> issue as you mentioned RGB v.s. grayscale?

Instead of having a enum option where the user needs to know detail 
information about his hardware, it becomes are mere boolean "subpixel 
antialiasing: On/Off".

Add to this that there are far more subpixel layouts than mere 
{h,v}{RGB,BGR}. In fact a much more useful configuration option (to be 
placed in the data base) would be subpixel geometry (stipple) masks for 
each color channel instead of a enum.

Of course subpixel arrangement masks are something that would perfectly 
fit into EDID data, but so far there's neither a standard EDID record 
nor an EDID extension block specified for this. And since I can't afford 
a VESA membership I also can not really make that suggestion directly.

BTW: XRandR reports display subpixel rrangement for each output in form 
of an enum, that carries the same values as the FreeType/FontConfig 
subpixel antialiasing settings (though I seriously wonder where XRandR 
takes these values from).

> This is a bit ugly workaround but somewhat realistic to me, you could
> have a separate configuration files named fonts-${HOST}.conf and set
> it to FONTCONFIG_FILE in your startup script in your shell.

Well, I already hacked something with $FONTCONFIG_FILE and this is 
what's the starting point for all the convoluted mess I outlined 
previously. Because with a nonstandard $FONTCONFIG_FILE you effectively 
have to replicate /etc/fonts.conf/fonts.conf, create per-host xdg 
prefixed include statements, i.e. something like

         <dir prefix="xdg">fonts-foobar</dir>

where foobar is set by the setup script at startup. And then you have to 
populate that folder itself. Add to this that XML is not really a file 
format you can easily process from the shell. Starting XSLT for setting 
this up... Somehow that strikes be as a little bit, well, misguided.

Lets face it: The aspects of glyph rasterization are a dynamic property 
and hence not really efficiently described by a set of static files. 
unless of course the files are in fact virtual files in a virtual/pseudo 
file system like sys/procfs; but to be effective, such a scheme required 
a different approach on file systems on the OS level, something along 
the line what e.g. Plan9 does (every user sees his own private file 
system, with arbitrary 9p resources overlay mounted in certain places).


Wolfgang