[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Font setup in "startkde".
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2004-08-28 23:00:18
Message-ID: 41310E82.4070603 () acm ! org
[Download RAW message or body]

This part of the code in the "startkde" script still has problems:

--------
# Activate the kde font directories.
#
# There are 4 directories that may be used for supplying fonts for KDE.
#
# There are two system directories. These belong to the administrator.
# There are two user directories, where the user may add her own fonts.
#
# The 'override' versions are for fonts that should come first in the list,
# i.e. if you have a font in your 'override' directory, it will be used in
# preference to any other.
#
# The preference order looks like this:
# user override, system override, X, user, system
#
# Where X is the original font database that was set up before this script
# runs.

usr_odir=$HOME/.fonts/kde-override
usr_fdir=$HOME/.fonts

# Add any user-installed font directories to the X font path
kde_fontpaths=$usr_fdir/fontpaths
do_usr_fdir=1
do_usr_odir=1
if test -r "$kde_fontpaths" ; then
     savifs=$IFS
     IFS="
"
     for fpath in `grep -v '^[ 	]*#' < "$kde_fontpaths"` ; do
         rfpath=`echo $fpath | sed "s:^~:$HOME:g"`
         if test -s "$rfpath"/fonts.dir; then
             xset fp+ "$rfpath"
             if test "$rfpath" = "$usr_fdir"; then
                 do_usr_fdir=0
             fi
             if test "$rfpath" = "$usr_odir"; then
                 do_usr_odir=0
             fi
         fi
     done
     IFS=$savifs
fi

if test -n "$KDEDIRS"; then
   kdedirs_first=`echo "$KDEDIRS"|sed -e 's/:.*//'`
   sys_odir=$kdedirs_first/share/fonts/override
   sys_fdir=$kdedirs_first/share/fonts
else
   sys_odir=$KDEDIR/share/fonts/override
   sys_fdir=$KDEDIR/share/fonts
fi

# We run mkfontdir on the user's font dirs (if we have permission) to pick
# up any new fonts they may have installed. If mkfontdir fails, we still
# add the user's dirs to the font path, as they might simply have been made
# read-only by the administrator, for whatever reason.

# Only do usr_fdir and usr_odir if they are *not* listed in fontpaths
test -d "$sys_odir" && xset +fp "$sys_odir"
test $do_usr_odir -eq 1 && test -d "$usr_odir" && (mkfontdir "$usr_odir" ; xset 
+fp "$usr_odir")
test $do_usr_fdir -eq 1 && test -d "$usr_fdir" && (mkfontdir "$usr_fdir" ; xset 
fp+ "$usr_fdir")
test -d "$sys_fdir" && xset fp+ "$sys_fdir"

# Ask X11 to rebuild its font list.
xset fp rehash

--------

There are two classes of issues here:

Are these actions necessary?

Are these actions sufficient?

Since Qt/KDE now uses FontConfig:

Is it necessary to add the KDE font directories to the X fontpath?

It is not sufficient to add the KDE font directories to the X fontpath.  The 
directory tree rooted with: $HOME/.fonts should already be registered with 
FontConfig, but the directory $KDEDIR/share/fonts might not be.  It needs to be 
in: "/etc/fonts/local.conf", but this will take more than a script.

If these directories do need to be added, to the X fontpath or to 
"/etc/fonts/local.conf", they should not be added redundantly.  Some of these 
directories are not, or might not, be KDE only font directories and therefore 
might already be in the X fontpath or accessible by FontConfig.

Running "mkfontdir" on the user's font directories is questionable.

The first issue is that this command has changed since this part of the script 
was first written.  The current command which comes with XFree86 requires the: 
"-e" parameter.  If it is run on a font directory without this parameter, it 
will remove the file: "encodings.dir".  I don't think that KDE needs this, but 
other programs might.

Second, running the command will only detect BIT MAPPED fonts unless the 
command: "mkfontscale" is run first, except for the case when the system is 
using a link:

	mkfontdir -> mkfontscale

In that case the command needs the: "-f" parameter in addition to the: "-e" 
parameter.  It is also possible that a font directory might have a link:

	fonts.dir -> fonts.scale

Which might also need to be considered.

Further, the current command mkfontscale has bugs in it (and these are probably 
caused by bugs in FreeType2).  So, if someone has edited the fonts.dir and 
fonts.scale files by hand to fix this, running the command will overwrite these 
changes.

Then there is the GS_LIB code:

--------
# Get Ghostscript to look into user's KDE fonts dir for additional Fontmap
if test -n "$GS_LIB" ; then
     GS_LIB=$usr_fdir:$GS_LIB
     export GS_LIB
else
     GS_LIB=$usr_fdir
     export GS_LIB
fi

--------

This has more issues which should be apparent to anyone that has read the 
GhostScript documentation.

But, the first issue which I encountered is that this doesn't check first to see 
if the directory is already in "GS_LIB" before adding it.

The previous code lists two user font directories:

usr_odir=$HOME/.fonts/kde-override
usr_fdir=$HOME/.fonts

as well as the possibility that additional directories are listed in:

	$HOME/.fonts/fontpaths

And then there are the two system directories:

	$KDEDIR/share/fonts/override
	$KDEDIR/share/fonts

Clearly, it would be necessary to check for all of these directories in GS_LIB.

However, as stated in the GhostScript docs, there are two additional issues.

GhostScript has two environment variables for font directories:

	GS_LIB
	GS_FONTPATH

The path: "GS_LIB" is searched first and this search is faster, but to be in 
"GS_LIB", the directory must have a "Fontmap" file.  If the directory doesn't 
have a "Fontmap" file it does not good to add it to "GS_LIB".  Directories 
without "Fontmap" files can only be added to "GS_FONTPATH".  It should also be 
noted that a search of "GS_LIB" will only find fonts which are listed in the 
"Fontmap" files.  Therefore, if it is actually possible that "mkfontdir" needs 
to be run then the "Fontmap" file won't be current and the directory would need 
its "Fontmap" file updated (no standard way to do this and it might be very 
slow) or be added to BOTH paths.

The "GS_LIB" path can also be built into GhostScript, but it isn't exactly the 
same.  The built in search path is called: "GS_LIB_DEFAULT" and the contents of 
this path are not going to be in the environment variable "GS_LIB".  They do, 
however, show up in the command:

	gs -h

which would need to be greped.

Since CUPS doesn't use the system's "GS_LIB" and "GS_FONTPATH", distros build 
the font search path into GhostScript, but you can't build $HOME/.fonts into 
GhostScript and due to a small bug in Bash, you might need to set it in 
$HOME/.bash_profile (on Linux) -- the same would apply to all font directories 
in $HOME to be added to "GS_LIB".

So, this is really something of a mess.

I note that I run my system without any of the above code in my "startkde" 
script and it works fine (but I don't have any 'override' fonts).  I therefore 
regard all of the above script code as totally unnecessary -- users should 
instead see that their system is configured properly.

And that is the final issue.  If the distro *has* configured the system 
properly, this script code is not only redundant; it is probably going to cause 
problems.

--
JRT

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]