On the way to solve the CUPS problem

I opened a bug report for the prob­lem (have a look at the relat­ed posts below) and got the response that it is a prob­lem in pstoraster. This means it is a prob­lem in ghost­script, not in CUPS.

So I had a look at pstoraster and seen that CUPS_FONTPATH is added to GS_LIB. The­o­ret­i­cal­ly it should solve my issue when I set CUPS_FONTPATH, but this assumes I can do it with­out CUPS dis­card­ing my settings.

Unfor­tu­nate­ly this assump­tion is not true. I tried it and I still see the same behav­ior as before.

Rea­son for the env pass­ing prob­lem in CUPS

Today I had the time to have a look at the prob­lem I have to pass the val­ue of the GD_LIB vari­able from CUPS to ghost­script: CUPS is set­ting this vari­able on its own and thus over­rid­ing my setting. 🙁

It seems CUPS is not check­ing if I have my own GS_LIB vari­able and adding its own path to the already set one. That is bad.

More prob­lems with CUPS (pass­ing env variables)

Sat­ur­day I had to print a post­script file. The file was gen­er­at­ed out of a tem­plate which I wrote myself by hand sev­er­al years ago. There I use a non-standard PS font which can not be changed. The font is not embed­ded, and I can print it via ghost­script by telling it the loca­tion where the font files are locat­ed (export GS_LIB=/path/to/dir1/path/to/dir2). Now that I switched to use CUPS as my printserv­er soft­ware, I had to teach it to set this for the call to gs (via foomat­ic). Unfor­tu­nate­ly I failed to get it work­ing via the CUPS config.

I added “SetEnv GS_LIB /path/to/dir1:/path/to/dir2” to cups.conf and restart­ed CUPS. This did not work. I added “PassEnv GS_LIB” to cups.conf, added an appro­pri­ate export of GS_LIB to /etc/rc.conf (just to make sure… I still had the SetEnv in cups.conf) and restart­ed CUPS. This did not work either.

As I just want­ed to print out some­thing and did not want to spend my time debug­ging this, I put a workaround into place: I moved gsc to gsc.bin and cre­at­ed a lit­tle shell script as gsc which sets the vari­able and starts gsc.bin.

At the next update of ghost­script this will break my print­ing (if I for­get 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 anoth­er workaround to me, than a real fix.