Bug 65123

Created attachment 2613 [details]
Patch for the "startkde" script.

This fixes the problem on my system.

Priority and Severity lowered.

This is a minor problem.

--
JRT

Why is it a problem if there are duplicate entries?

If duplicate entries causes problems then that would be better fixed in gs itself IMO.

I rather not run gs from within startkde for performance reasons.

> If duplicate entries causes problems then that would be better fixed
> in gs itself IMO.

It produces duplicate entries in the environment variable.  Scripts should ALWAYS be written to avoid this -- it is just good programing practice.

> I rather not run gs from within startkde for performance reasons.

GhostScript is a bit retarded.  It doesn't have a: "ghostscript-config" file or something like that.  The only way to get the status information is to run:

     gs -h

This doesn't take any longer than if it had a proper script to provide status information.

--
JRT

# 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 issues which should be apparent to anyone that has read the GhostScript documentation.

The issue which I encountered (and originally reported) is that this doesn't check first to see if the directory is already in "GS_LIB" before adding it.

The font setup code (bug 88461) 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, and add them if they were not there.

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 do any 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 -- if new fonts have been added to a directory (without using KFontInstall) -- 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 

I am making the scope of this bug larger to include all font setup code in the: "startkde" script.

I first suggest that this code really shouldn't be in the script, but it is necessary if a user doesn't have their system configured correctly.  So I suggest that although we continue to install the version with this code that we also provide a copy without the code and suggest that distros use that and have their system set up correctly.

The script code is going to have to be a little more complex to work correctly.  I attach my current work-in-progress script code to replace Lines 175-200.  And, yes it is longer because it checks for more things to avoid messing up things that are already there and to fix at least one bug in the existing code.

The original issue of the GS_LIB path for fonts in the $HOME directory is impossible to solve using CUPS unless CUPS is fixed so that it will use the GS_LIB path.  Any suggestions will be welcome.

-- 
JRT

Created attachment 10567 [details]
Current work-in-progress code

Created attachment 10568 [details]
Version 01

Small error.

-- 
JRT

*** Bug 88461 has been marked as a duplicate of this bug. ***

Hello,

Can you still reproduce the bug with the latest KDE 4 release?

Thanks.

The same font related issues are in KDE-4 TRUNK.

Seems like the startkde code is the same 10 years later, but still wonder if this is still relevant.

https://github.com/KDE/plasma-workspace/blob/b2b4959a905e2ddfdfcdc637a943464ffa309ae5/startkde/startkde.cmake#L180-L187

startkde has been replaced with a new compiled C++ program called "startplasma", so this is no longer relevant.