- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] fontconfig q
- From: "Christopher Vance" <cjsvance@xxxxxxxxx>
- Date: Sun, 20 Aug 2006 21:16:07 +1000
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MKysDlrMv7i/J2oApkuzSFl/qz6tdZ6veqNOXY0O5PT/GquecRWeYHZHQyHEicJNrR+De/YvfpLR9gKtTzlr5YZAmAGqyv7W+Y9A2cZh4NsjHlcwMjvzGU1sJ+Tf0+3RQIuL27l2hzbiH+M+v1PTp7FPiSErtSx5aM0DJJjCN4k=
Firstly, thanks for the reply.
On 8/20/06, Jeff Waugh <jdub@xxxxxxxxxxxxxx> wrote:
<quote who="Christopher Vance">
> Prior to fontconfig, I think I understood how things worked.
> I'm trying to get a selfcompiled copy of vlc running on the thin clients,
> and I'm trying to work out whether fontconfig needs to run on the xfs
> server, on the X server (= xfs client), or both.
Ok, first part of the answer: These technologies are totally unrelated. :-)
I think you mean xfs and fontconfig are unrelated. You might possibly
be saying that vlc and fontconfig are unrelated, but I'm only faced
with a fontconfig problem because it's an (indirect?) dependency of
vlc, which is why I'm going for the first understanding.
xfs only works with the old school X fonts system, which were all 'server'
side (ie. the machine that does the display renders the fonts; in your case,
the X terminal). Modern X font rendering is all done 'client' side (ie. the
machine running the piece of software, no matter where it is displayed). So,
you'll have to readjust to font rendering with modern X and common toolkits.
For almost everything else running on the system, xfs is all I need
and seems to work well enough.
A GTK+ application, for instance, uses fontconfig to grok which fonts are
available and how their names map (you might remap 'Arial' to 'Nimbus', or
even use individual characters from another fonts if some are missing from
the one you chose). It uses Pango to do a lot of the internationalisation
smarts such as complex scripting or right-to-left rendering. It will use
freetype for doing the client side font rendering. It may use the RENDER X
extention to accelerate the display of fonts on the X server. But it does
*not* use any of the fonts from the X server config (the 'Fonts' paths in
xorg.conf, including the xfs tcp/unix path).
I'm trying hard to use as little GNOME-related stuff as possible, but
don't seem to have been able to avoid it totally. :-(
All the X server really needs these days is the Fixed font, and possibly
some others for legacy application compatibility. :-) It doesn't matter what
fontconfig thinks on the machine that runs the X server because it no longer
has a role to play in the rendering of fonts. Just the display.
Okay, so it's the thin client installation of fontconfig I have to
fix. If the fonts are not actually on the displaying machine, I guess
I might need to whack some more directories into my server's
/etc/exports, and name them in my clients' /etc/X11/xorg.conf. Given a
lack of /etc/init.d stuff, do I need to do anything to teach
fontconfig about the content of the new font directories? (Preferably
no, but if I have to do something, I'd rather do it once in the nfs
directories, rather than on every boot for about ninety identical