I opened a bug report for the problem (have a look at the related posts below) and got the response that it is a problem in pstoraster. This means it is a problem in ghostscript, not in CUPS.
So I had a look at pstoraster and seen that CUPS_FONTPATH is added to GS_LIB. Theoretically it should solve my issue when I set CUPS_FONTPATH, but this assumes I can do it without CUPS discarding my settings.
Unfortunately this assumption is not true. I tried it and I still see the same behavior as before.
Today I had the time to have a look at the problem I have to pass the value of the GD_LIB variable from CUPS to ghostscript: CUPS is setting this variable on its own and thus overriding my setting. 🙁
It seems CUPS is not checking if I have my own GS_LIB variable and adding its own path to the already set one. That is bad.
Saturday I had to print a postscript file. The file was generated out of a template which I wrote myself by hand several years ago. There I use a non-standard PS font which can not be changed. The font is not embedded, and I can print it via ghostscript by telling it the location where the font files are located (export GS_LIB=/path/to/dir1/path/to/dir2). Now that I switched to use CUPS as my printserver software, I had to teach it to set this for the call to gs (via foomatic). Unfortunately I failed to get it working via the CUPS config.
I added “SetEnv GS_LIB /path/to/dir1:/path/to/dir2” to cups.conf and restarted CUPS. This did not work. I added “PassEnv GS_LIB” to cups.conf, added an appropriate export of GS_LIB to /etc/rc.conf (just to make sure… I still had the SetEnv in cups.conf) and restarted CUPS. This did not work either.
As I just wanted to print out something and did not want to spend my time debugging this, I put a workaround into place: I moved gsc to gsc.bin and created a little shell script as gsc which sets the variable and starts gsc.bin.
At the next update of ghostscript this will break my printing (if I forget that I have this workaround in place), so I should try to get some time to fix this. Maybe I can fix this by adding “env GS_LIB=…” to the call of gs in the ppd, but this seems more like another workaround to me, than a real fix.