On 12/20/2012 10:33 AM, Per Jessen wrote:
Well I think that starts with, if you have something that creates it's own printer codes that includes more than mere image data, like input or output bin selection codes etc,
Typically users will be printing from *office or Acrobat, and select the usual options - papersize, input tray, type of paper etc.
that you're simply not supposed to be using any filtering in the spooler period. For that you need to tell the app to use "-o raw" or equivalent option or create a raw spooler queue that includes no filtering. Then do your custom post processing yourself in your app or in your own app-printer glue.
Hmm, that sounds reasonable.
If you're not actually interested in generating pdfs but really printing, and your source data is pcl, then you have a decent option in the form of just inserting some new pcl into the print job.
It's more complicated than running a command, but it's sure super efficient at run-time.
Depending on how complex the main print job is, and depending on what you want in the watermark, it may be almost trivial to add it to each job.
I have some examples of form overlays like invoices, done in straight pcl. My application prints a page of text, and in that page is a tiny code that gets replaced on the fly with an entire form overlay file. The overlay file basically is just an image printed in pcl, with a few bytes of code manually added at the beginning that says: - remember current cursor position - move cursor to 0,0 home position
<full page image of form>
- restore cursor to remembered position
That's exactly the sort of thing I'm looking for! Any chance you can post an example of how you do this?
You can also load the form into the printers memory and then just invoke it any time you want with a small code, or tell the printer to just print it on every page in addition to any other incoming print data, until specifically told to stop, or until the printer loses power.
Yeah, I've been playing with this too, but my Kyocera FS-C5015N plainly refuses to print the form overlay. Just in case I'm doing something wrong:
a) open the overlay document, print with "Save to Form-A". Printer confirms it was saved. b) print other document with "Use Form-A on all pages"
The overlay is never printed. I'm using a small 8Mb RAM disk in the printer, and I have confirmed that the form is stored.
I can help a lot right here myself for free but it may take us a while before you have what you envision as your final goal because the back & forth cycle is slow by mail list, and it sounds like I would probably want to start with a very simple proof of concept demo print job that isn't actually useful, and walk you up from there by stages, no jumping right to the end.
For the time being, I've written a small utility that deals with the PCL etc, and this works, it's just kludgy in the extreme. I'd much rather use the forms solution, alternatively what you described above with PJL.
If you can say more exactly what kind of data you're dealing with, how it's actually generated, and what you want to do with it, I can be a lot more specific and give actual examples you can try. But a pcl job can be manipulated so many different ways that it's impossible to say what way makes most sense for you without knowing more.
Brian, first of all, thanks very much for taking the time to write all this up. Much appreciated!
I'm not trying to do anything particularly special, I think - I really just want a 2nd printer queue where each page is printed with an overlay consisting of a logo (upper right hand corner) and an address (single text line on the bottom). The overlay original is just an openoffice document in PDF format.
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. 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.
If you're talking about windows desktops sending jobs over the lan, then it's the windows printer driver generating the actual print job. You could have set that up two different ways.
One is you install only a generic postscript printer driver on the windows desktop, all of them, and cups takes that in natively the same as if it were from a local linux app. But in that case you wouldn't have access to any special printer features like selecting paper source.
Or you install a printer-specific driver on the windows desktop, and cups does not modify the print data at all, just spools it. In that case you usually can't modify the print job on the fly unless the windows printer driver just happens to be on that generates PCL5 or lower or PS. Also the printer has more than one printer-specific driver that might be used, so you'd need to make sure all desktops use the same kind of driver if you're going to try to modify them on the fly. They all have to use the same pcl6 or kpdl or whatever, not whatever they want.
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. 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.
If it does support PCL5, then you might install pcl5 drivers on all desktops, to make it so that you will be able to modify the jobs as they go through pretty easily.
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.
KPDL or any other printer-specific language is basically out of the question unless you want to hunt down language specs and become an expert in that particular language just to support one printer (I don't!) Maybe KPDL is easy to work with like pcl5 and you can go that way. Ensure all desktops use a kpdl driver and modify that on the fly in a print filter script. I wouldn't pin a lot of hopes on that :)
So basically I don't think you can do this without getting pretty fancy and involved, or without replacing random printers with at least one that supports pcl5, or losing the ability to specify printer-specific special commands like selecting paper sources, or unless you get lucky and kpdl turns out to be easy to work with as pcl5.
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.
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
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.