Brian K. White wrote:
We have a number of Kyocera printers, that will do KPDL or PCL6. Typically users will be printing from openoffice or Acrobat, and select the usual options - papersize, input tray, type of paper etc. The only automated application is for billing and that produces invoices in pdf format.
Since you say it's users printing from openoffice and acrobat, I think the whole pcl thing doesn't apply. You said pjl which made me think you were dealing with a local application running on the linux box that generates pcl like a lot of legacy back end apps did.
Given what you just described, I don't know a practical way to get what you want without either replacing a printer with one that knows PCL5 or lower or PS so that you can modify the job on the fly without breaking it. Several items combine to make this difficult without changing something somewhere.
Both openoffice and acrobat exist on linux and windows and mac, and they each print differently.
If you're talking about linux, then openoffice and acrobat generate PS, not pcl.
Yes, I'm only talking about Linux, we're a 100% Linux-shop.
PS can be read and modified on the fly without breaking it. I don't know how the user could select printer features like paper source unless it's the cups driver/ppd that knows how to do that and they are selecting in a cups/spooler dialog, so cups is applying those commands not the application. In that case you should be able to do something in the filter script.
Yes, when you're in e.g. Acrobat and hit you Ctrl-P, you're presented with the printing dialogue. The "Properties" button will show you the list of option from the PPD.
Also, when a printer says it understands PCL6, that may or may not mean it also understands PCL5 or lower. PCL6 is a binary format that you can't modify on the fly simply.
Ah. There seems to be manuals available for up to PCL5, but I can't find anything for PCL6.
Many newer printers support PCL6 but not PCL5 or lower because it requires more cpu and ram in the printer to support PCL5 and requires paying a license to HP for each printer. Older laser printers and more expensive newer laser printers often support pcl5. It's worth a shot to see if yours does.
I need to test 4 different models, I guess this is this a matter of simply feeding the printer with some raw PCL5. Just in case you've got an idea - why would using the forms setup not work for me? There must be something I'm missing. I've opened a support case with Kyocera, but I'm not holding my breath.
If it only supports pcl6, you might make sure all desktops use the pcl6 driver instead of the kpdl one, and then on the server you could have the spooler read the pcl6 with ghostpdl and convert it to something you can manipulate like pdf, and then let cups convert the pdf to the printers native data like back to pcl6 or kpdl etc. You _might_ be able to retain the ability for the users to do things like select paper source IF ghostpcl can report those settings to you somehow when it reads the pcl6. Then if you can get get ghostpcl to tell you what options the user set, then you can possibly turn around and tell them to cups so they get created again in the new modified print job. I have no idea if any of that's possible.
Hmm, setting the various options will probably become moot anyway - I still intend this to be a separate printer queue which only prints on plain paper, size A4, with the letterhead overlay.
Or another lucky break possible, you said pjl originally. MAYBE all the special printer commands are done in PJL regardless if the rest of the print job is in pcl6 or kpdl? In THAT case you might be able to make it work. Because it's not too hard to parse the pjl and collect it, strip it from the main job, do your graphics manipulation on the main job by converting from pcl6 to pdf and back to pcl6, and then re-applying the pjl to the beginning.
The printjob (when I get it in a cups filter) looks like this: PJL stuff (encapsulated by PJL UEL markers) postscript PJL stuff (encapsulated by PJL UEL markers) Sofar I have written a utility that reads the whole thing, extracts the postscript, does the overlay with pdf+ps, then reapplies the PJL, and passes it back to cups. It works, but it's kludgy and slow.
I'd try sending a test pcl5 job to the printer, raw, don't let cups try to apply any driver. If the printer prints it then that's your easiest path, both in terms of your work and the work the server does for each job, because you won't have to do any graphics conversions, just inject a small amount of data.
echo -en "\033EPCL5 test \033(s3Bemphasised\033(s0B \033(s1Sitalics\033(s0S\014\033E" |lpr -o raw -P printername
Thanks, will try that.
Failing that I'd try to figure out if the pjl idea is true that all the special commands are done in a pjl header.
The PJL actually looks very simple: ^[%-12345X@PJL @PJL JOB NAME = "test4" DISPLAY = "2249 per test4" @PJL RDYMSG DISPLAY = "2249 per test4" @PJL SET ECONOMODE=OFF !R!CRES;SCRN0;RGBL0,0;RGBL1,0;RGBL2,0;HUE0,0;HUE1,0;HUE2,0;HUE3,0;HUE4,0;HUE5,0;HUE6,0;LGHT0,0;LGHT1,0;SATU0;EXIT;^[%-12345X@PJL ENTER LANGUAGE=POSTSCRIPT -- Per Jessen, Zürich (4.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org