Arch Linux User Repository

Unfortunately this was not the fix (my fault). Instead of /opt/samsung, which is not needed, use a link from /usr/share/cpus/model/uld-samsung to ../../ppd/suld (i.e. to /usr/share/ppd/suld; use the absolute path if you think this is more appropriate). (in Samsung's package, /usr/share/cpus/model/uld-samsung is a link to /opt/samsung/printer/share/ppd which apparently is the only place where that path is still used)

@gschwarz Thanks for helping getting this fixed! I added another symlink from /opt/samsung/printer/share/ppd -> /usr/share/ppd/suld, can you check if that fixes the issue?

First of all, thanks for taking on this issue. As expected from my previous investigations, the one link is not sufficient. One also needs to create /opt/samsung/printer/share and there create a symlink named ppd to /usr/share/ppd/suld. So far I have not found out which component is looking there (probably for the cms files).

(yes, /usr/opt was a mere typo)

@gschwarz I added a symlink from /opt/smfp-common/printer/lib -> /usr/lib, can you check if that fixes the issue?

@christoph.gysin & @gschwarz: I can confirm everything that gschwarz said. Difference being that I installed samsung-unified-printer-driver on a pristine distribution with no previous printers installed. And YES, the HP script solved all the color problems on the CLP-315W. After running the script, I even did not remove or reinstalled the printer, just restarted the CUPS deamon. Also I do not have /usr/opt/samsung/printer, actually I do not have /usr/opt at all (typo?). No difference between the new PPD and CMS CLP-310 files under /opt/samsung/printer/share VS the preexistent files under /usr/share/ppd/suld (although under /suld PPDs are gzipped). I noticed that the script install two soft-links (/usr/share/ppd/uld-samsung and /usr/share/cups/model/uld-samsung) both pointing to /opt/samsung/printer/share/ppd. Gotta analyze the script more carefully.

I installed samsung-unified-printer-driver over a previously installed original Samsung linux driver and then one by one tried to remove/rename components from the latter, after each step removing and reinstalling the printer (to make sure the problem is not caused on printer configuration time only, which a later test confirmed is not the case: it's a print-time issue). Renaming the uld-samsung link to /opt/samsung/printer/share/ppd in /usr/share/ppd did not make a difference, however subsequently renaming /opt/samsung to /opt/samsung.off did bring up the incorrect color palette, as did renaming/usr/opt/samsung/printer or renaming /opt/smfp-common or /opt/smfp-common/printer or just /opt/smfp-common/printer/lib (the latter just contains a single file, libscmssc.so). Renaming /opt/smfp-common/printer/bin does not have an effect. So it appears that /opt/smfp-common/printer/lib/libscmssc.so as well as /opt/samsung/printer (which essentially contains only share/ppd including share/ppd/cms) are hardcoded somewhere. Indeed a strings on rastertospl yields the first path. (yes, lacking the source code sucks)

@gschwarz Can you try to check what else is different when using the Samsung installer? I'll happily apply a fix if you can isolate what causes the difference in behaviour.

Did so, but it does not make any difference (nor did ln -s suld/cms cms in /usr/share/ppd instead)

@gschwarz Can you try if it works correctly if you move the cms folder directly under /usr/share/ppd:

$ sudo mv /usr/share/ppd/suld/cms /usr/share/ppd/