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
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
