Thomas Taylor wrote: Hi Tom, yeah, that one is my backup plan :-) Because I'm considering skipping preprinted letterheads altogether, I was hoping to add the letterhead template before printing, so I'd only need one run through the printer. Thereby saving electricity, printer wear etc. -- Per Jessen, Zürich (2.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 12/20/2012 2:19 AM, Per Jessen 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=g… This build is configured somewhat narrowly. It only has a few of the most generically useful output drivers compiled in. For all other oddball printers and graphics formats, I say just use any number of other converters from any of the common formats this can output. It also has all X11 support stripped. Then again this has one thing added that's not there by default, which is built-in tiffg3 output. It can produce output that is exactly perfectly native input for hylafax so that hylafax will not do any converting internally. Saves a lot of cpu and ram work when 50 application servers with hundreds of users each are all sending faxes over the net to one hylafax server. 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. Install the appropriate yast repo from the link above, then "zypper in ghostpdl" If you're on 12.2 or newer, using the 12.1 version of either the rpm or the entire repo should be no problem. After install, just run "pcl2pdf file.pcl" It should generate a file.pdf If your print files are named *.pcl then it will strip .pcl and add .pdf to make the output filename if none specified: pcl2pdf infile.pcl creates infile.pdf If your print files are not named *.pcl then it will just append .pdf to the full input filename: pcl2pdf report.prn creates report.prn.pdf If you specify an output filename it will do exactly that: pcl2pdf /path/to/inputfile /path/to/outputfile creates /path/to/outputfile You can replace either input or output or both with "-" for stdin/stdout mypclwriter |pcl2pdf - output.pdf pcl2pdf somefile.pcl - |mypdfreader mypclwriter |pcl2pdf - - |mypdfreader You can also use with no options if both in and out are piped: mypclwriter |pcl2pdf |mypdfreader -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

-----Original Message----- From: "Per Jessen" &lt;per(a)computer.org&gt; Sent: Thursday, December 20, 2012 7:35am To: opensuse(a)opensuse.org Subject: Re: [opensuse] watermarks when printing with cups ? Brian K. White wrote: 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. 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(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

On 12/20/2012 10:33 AM, Per Jessen wrote: 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. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Per Jessen wrote: Didn't work - "EPCL5 undefined". -- Per Jessen, Zürich (6.3°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org

Ken wrote: Almost certainly possible, but it would only work for openoffice writer, not for acrobat. It also complicates the PC setup/process for everyone. -- Per Jessen, Zürich (4.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse+owner(a)opensuse.org