Sorry, but I don't see anywhere above that you confirmed that the test I asked for in post #44 worked for you. In fact, you said (post #51):
'So I do not need to do "lpr -P <printer name> -oraw ko-nodebug-cut001.ps", since there is no problem'
To me, that sounds like you didn't use lpr, but some other method, which is why I asked for clarification of how you printed the output.
Sounds like there been some miscommunication, so if you ran the lpr test, and it worked okay, then I think we have all we need.
I will ping Till tomorrow, and we'll get these Toshiba printers added to the "exceptions list" of printers that can't use the compression filter(s) in Postscript. Hopefully he can get a cups update out in the near future.
Once that happens, you will need to do reset the cups filter to the default - I think this does it:
lpadmin -p printer -R pdftops-renderer-default
Jacques,
Sorry, but I don't see anywhere above that you confirmed that the test I asked for in post #44 worked for you. In fact, you said (post #51): cut001. ps", since there is no problem'
'So I do not need to do "lpr -P <printer name> -oraw ko-nodebug-
To me, that sounds like you didn't use lpr, but some other method, which is why I asked for clarification of how you printed the output.
Sounds like there been some miscommunication, so if you ran the lpr test, and it worked okay, then I think we have all we need.
I will ping Till tomorrow, and we'll get these Toshiba printers added to the "exceptions list" of printers that can't use the compression filter(s) in Postscript. Hopefully he can get a cups update out in the near future.
Once that happens, you will need to do reset the cups filter to the default - I think this does it: renderer- default
lpadmin -p printer -R pdftops-