Xresources and Xdefaults should make no functional difference.
Is it possible that the culprit is sitting somewhere in your /etc/profile.d/* and gets loaded from there? Any chance there are some leftovers you forgot about (e.g. alternative freetype runtime scripts)? Just in case, examine both local and global $SHELL config files.
I've looked through /etc/profile.d/ as well as /etc/skel/ and there is not reference to Xft anything within either insofar as I can tell. At this point I'm less concered about how my fonts look than I am with figuring out why things are different between the two machines. This is nitpicky, OCD stuff, but that how I roll, I guess.
Edit: I assume your local .Xdefaults is sourced every time you log in to your $HOME:
xrdb -load ~/.Xdefaults
I don't believe I have anything explicitly sourcing .Xdefaults anywhere at all. In my experience .Xdefaults seems to be automatically reread each time I invoke an X11 application. I've kept it this way because it makes things easy and I don't need to mess around with xrdb. The current revision of the wiki notes that .Xdefaults is "deprecated" but it seems to work well for me.
]]>battlepanic wrote:on both machines
Font newbie question: Does being able to see sub-pixel rendering depend on the monitor you're using?
Yes, and no.
Yes in the sense that the design of your monitor matters in order for the subpixel rendering to achieve its intended effect. No in the sense that it will always change the look of your fonts, but it must be properly configured for your particular monitor and in some cases it is simply not going to work correctly.
Sub-pixel rendering doesn't make sense on CRT monitors. If you are using a CRT, you definitely do not want this. It is meant to be used on flatscreen (i.e. LCD, OLED, etc.) monitors and it typically allows for a higher effective vertical resolution at the expense of color fidelity. Some people like this look and some people don't.
The pixel geometry on your LCD monitor matters. If sub-pixel rendering is turned on, whatever software is rendering your fonts needs to know the physical layout of the red, green, and blue pixel components on your monitor. On an flatscreen monitor, the left to right order within each pixel is typically red, green, then blue, though this is not always the case.
A monitor with a high pixel density would also make it more difficult to discern whether or not sub-pixel rendering is turned on by virtue of the fact that as pixel density increases, it becomes more difficult to see the individual pixel components.
]]>on both machines
Font newbie question: Does being able to see sub-pixel rendering depend on the monitor you're using?
]]>Is it possible that the culprit is sitting somewhere in your /etc/profile.d/* and gets loaded from there? Any chance there are some leftovers you forgot about (e.g. alternative freetype runtime scripts)? Just in case, examine both local and global $SHELL config files.
Edit: I assume your local .Xdefaults is sourced every time you log in to your $HOME:
xrdb -load ~/.Xdefaults
Do you get the same output when you issue
xrdb -q | grep Xft
?
I get no output when issuing that command on both machines. I should note that I'm using an .Xdefaults file as opposed to .Xresources. Because of this, I believe the resources aren't cached, but rather sourced from .Xdefaults every each time an X11 program is invoked. This has just been my personal preference as I've found it to be more convenient for tweaking X resources.
In any event, "xrdb -q | grep -i xft" produces no output on both machines. I've also scanned both .Xdefaults by hand to confirm that there is no mention of Xft.
I've also created a new user on both machines to rule out the possibility that it may be a stray configuration file existing in my home directory on one of the machines. On machine A the new user still gets sub-pixel rendering whereas on machine B the new user does not. This seems to suggest that whatever is overriding my fontconfig is being applied system-wide.
]]>xrdb -q | grep Xft
?
]]>On machine A firefox et al. use subpixel rendering, on machine B, they do not. This suggests to me that there is another policy somewhere that is overriding my system-wide fontconfig settings.
I can confirm that adding the Xft.* resources to my .Xdefaults and setting Xft.rgb to "none" does seem to disable the sub-pixel rendering. It appears that this overrides anything defined via fontconfig but the underlying mystery remains.
So, I have two systems withouth Xft resources defined and identical fontconfig settings yet they render fonts differently. Is there some other place that font rendering can be set? I suspect there is a configuration file somewhere that I am overlooking.
Note that firefox is not ignoring fontconfig completely. I have various font-specific settings (font substitution, hinting, etc.) specified via fontconfig and firefox respects those settings. This further suggests that fontconfig sub-pixel rendering settings aren't simply being ignored, rather they are being overridden by something.
]]>xrdb -load ~/.Xresources (or .Xdefaults)
and put the following line in your .xinitrc so that it gets loaded every time you start your WM.
]]>Check your .Xresources -- FF uses it to adjust font settings.
I checked my home directory and I don't have an .Xresources file. I do have an .Xdefaults file, though it doesn't not contain any resources that mention Xft. Could these settings be found in another file?
]]>Edit: the options you should look for and modify accordingly:
Xft.dpi: 96
Xft.antialias: 1
Xft.rgba: rgb
Xft.autohint: 0
Xft.lcdfilter: lcddefault
Xft.hinting: 1
Xft.hintstyle: hintfull
I've tried to disable sub-pixel rendering via fontconfig by creating the relevant symlink:
# ln -s ../conf.avail/10-no-sub-pixel.conf /etc/fonts/conf.d/10-no-sub-pixel.conf
I have also made sure that this is the lowest-numbered symlink in the /etc/fonts/conf.d directory.
Though I don't think it should matter, I have also ensured that the following files do not exist:
$ rm -rf ~/.fonts.conf.d/
$ rm -rf ~/.fonts.conf
$ rm -rf $XDG_CONFIG_HOME/fontconfig/conf.d/
$ rm -rf $XDG_CONFIG_HOME/fontconfig/fonts.conf
I'm not running a desktop environment and I am using Openbox as my window manager. Currently, chromium doesn't use sub-pixel rendering on its fonts though I'm finding that firefox and openbox do display fonts using sub-pixel rendering despite the aforementioned symlink.
I suspected maybe gconf might have something to do with this but I uninstalled it and the problem still persists.
I am confused as to why different applications would display the fonts differently. Is there some other mechanism for controlling sub-pixel rendering that I am overlooking?
]]>