-----Original Message----- From: "Per Jessen" <per@computer.org> Sent: Thursday, December 20, 2012 7:35am To: opensuse@opensuse.org Subject: Re: [opensuse] watermarks when printing with cups ? Brian K. White wrote:
Sorry I thought you knew about the the ghostpdl package I have on OBS since you were familiar with pdftk which I also maintain, but pdftk is in the actual distro and ghostpdl isn't so I guess that wasn't a given.
http://software.opensuse.org/download.html?project=home:aljex&package=ghostpdl
I think I did in fact find ghostpdl, but I skipped it after a while because it would only do pjl -> other which isn't quite what I'm after.
It does take in PCL (PCL5 and lower) and PXL (PCL6) and output ps, pdf, png, jpg, tiffg3, tiffg4, a handful of others I don't remember but all I ever use is pdf and tiffg3.
In other words it's optimized for non-interactive headless use in print/fax/email filters and web cgi's etc.
You shouldn't have to strip the PJL from your print files. Many of my own print jobs include PJL routinely. ghostpcl interprets it at least as far as I've encountered. Any new print job that hasn't actually been tried yet may include commands or constructs that the interpreter fails to handle, but in general it understands pjl, pcl and I think hpgl too. "PCL" and "hplaser" usually actually means all three together.
The cups filter I'm working on will use: ps2pdf to convert the cups print job to a pdf. use pdftk to add a letterhead (option background) then convert back to ps with pdftops. I would prefer not having to convert to PDF, but I haven't found a way of only working with postscript for overlaying the letterhead. The above fails because ps2pdf doesn't understand PJL, so can't produce a PDF. I see I can use pcl2pdf to produce the pdf, but how would I go about retaining the PJL for passing on to the printer? ---------------- 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, 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. 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 The image needs to be specially prepared, which is just printing it to file with an hplaser driver, and then manually stripping off some of the job control, page control, and printer setup & reset codes from the beginning and end. It both is and is not as hairy as it sounds. pcl is pretty easy to follow at least for basic init codes. raster image data and downloaded fonts etc are a big binary mess but even those have explicit start and stop codes you can read. Anyway that whole file gets inserted into a print job almost anywhere in the print job, like the top-left corner. The printer gets a few bytes into the print job, draws the form all over the whole page, goes back to the top-left corner a few bytes in and resumes the print job where it was before, and the two different sets of data are overlayed on the same page as long as there is no page eject or printer reset in the form overlay file. You can get a lot more crisp perfect looks and efficient data size as well by using hpgl to draw the form instead of using a pcl raster image of a form. 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. If the watermark is static, then that will be easiest because you can generate it once and just have the script apply it the same way every time. If the watermark should change with every job, that may still be easy if it's just going to be some text. If the watermark is going to be raster image, and dynamic, well that's doable to just requires yet more scripting to run maybe a ghostscript command to generate the image to a temp file every time. If you're working with pcl and you want to make your own nice custom forms and have it both look nice and be efficient, and you don't want to wade into the world of PCL, I can refer you to a real expert consultant who will give you basically perfection. 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. PCL is actually a really handy and really efficient "language". It has commands to do _anything_ and yet it's all very small escape codes that follow a very simple syntax, and it can be generated from simple shell scripts and even parsed and edited on the fly to some degree. And drawing a form in hpgl is pretty much like sending instructions to a plotter pen or programming in LOGO. The whole form is a short list of plain text commands then. You make changes to it in vi or text editor of your choice as long as it doesn't modify the escape chars or the line endings. You can have a script insert per-job changes on the fly with sed maybe or by just appending more commands maybe etc. But PS is even more functional because it's actually a full programming language not just some control and markup codes, not to mention it translates almost 1:1 to pdf so these days pcl isn't used much as a source document format any more. 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. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org