2

I have a program that generates a PDF as output. If I send this file to a printer using the Adobe viewer, it prints exactly as wanted. In particular, the application is printing labels and there's a requirement that every last pixel on the page is used, i.e. no margins whatsoever.

I'd like to try and automate this process. GhostScript seemed a logical choice. I used the command lines

gs -dBATCH -dNOPAUSE -sDEVICE=psmono -sOutputFile=A4_300.xxx -sPAPERSIZE=a4 A4_Print.pdf

... or alternatively 

gs -dBATCH -dNOPAUSE -sDEVICE=ljetplus -sOutputFile=A4_300.xxx -sPAPERSIZE=a4 A4_Print.pdf

I can send the output file, A4_300.xxx, to the printer via LPR and it almost prints well, but there's about 6-8 mm missing on all sides, i.e. there's a margin being enforced, and the text that should be printing in that area is actually being cut off.

Paper size should be a4, and that much is working correctly. But how can I arrange for the output to fill the whole page?

The output device is "some kind of HP laser printer"; I haven't seen the physical device. A similar printer I tested with was able to process output both for "psmono" (that produced PostScript) and "ljetplus" (binary, but printable).

Any advice, please?

Carl Smotricz
  • 66,391
  • 18
  • 125
  • 167
  • You say you're sending your (either PDF, or PCL) printfiles *"to the printer via LPR"*. May I ask: from which print client OS? And is it a different from your successful printouts using *"Adobe Viewer"*?? -- If so: have you considered that your LPR client OS may be using a different driver setup compared to your Adobe Viewer OS, which defines different printable areas and margins for A4 media? – Kurt Pfeifle Jul 30 '10 at 19:03
  • Adobe was running on a KUbuntu configuration identical to that on which I shipped my file to `lpr`. I could try doing it on the very same machine, but I don't think that's where the difference came from. – Carl Smotricz Jul 30 '10 at 19:31
  • If it's different machines, the potential for different CUPS printqueue configurations is very real. Check the following 3 points first: (1) look at the difference of the files `/etc/cups/ppd/[yourprintername].ppd` on each of the computers - (2) look at the difference in the output of this shell command: `lpoptions -d [yourprintername]` - (3) look at the difference in the output of this shell command: `lpoptions -l -d [yourprintername]`. "1" proofs or disproofs the "same driver" on the 2 systems. "2" and "3" (in case of same driver) proof or disproof "same default settings". – Kurt Pfeifle Jul 30 '10 at 19:45
  • Thanks much for your efforts! I will have to wait till Monday to make these checks, and will probably send more upvotes your way then. – Carl Smotricz Jul 30 '10 at 19:50
  • 1
    Oh yes, upvotes! Yummie, yummie.... ;-) – Kurt Pfeifle Jul 30 '10 at 19:54

1 Answers1

2

First of all: are you sure that your printer is physically able to print edge-to-edge? Which printer model is it?

It may well be that the printer itself enforces the "missing 6-8 mm on all sides". Since you see the margin "area actually being cut off", it means the printer indeed receives the complete image, but it crops the image to what appears as *ImageableArea keywords in PostScript printer PPDs (PS Printer Description files).

If your printer supports edge-to-edge printing indeed, then you may need to enable it as a default...

  • ...by some semi-secret setting in the front panel menu (if your printer has s.th. like that), or...
  • ...by accessing the web-based printer configuration panel from your computer's browser (should your printer support that), or...
  • ...by logging into the printer via telnet, rsh, ssh or msh (depending on your printer to allow this).

The actual procedure to set this depends on your printer model. It should be described in the printer manual.

If you are unlucky, the device simply doesn't support borderless printing. Then buy or find a model that does what you want ;-)

Update: I had missed your statement "If I send this file to a printer using the Adobe viewer, it prints exactly as wanted." From this I conclude that your printer must indeed be supporting borderless printing.

If your LPR client uses any form of PPD (as is the case if you print via CUPS, f.e.), then check out my hints about modifying PPDs (which also works for Windows systems) here:

Most likely you do not need to finetune your Ghostscript output; it is fine as the cropped printouts show.

Most likely you need to tweak your LPR client so that its "driver" does not destroy what you want to send to the printer.

Community
  • 1
  • 1
Kurt Pfeifle
  • 86,724
  • 23
  • 248
  • 345
  • This sounds like good advice, thank you very much! However... the Java software producing the output (and lpr) will ultimately be running on a Linux machine I'm unable to change the configuration of. If I can't get at the PPDs, is there something I can do with the file that's going to lpr? Any options I can pass to lpr? – Carl Smotricz Jul 30 '10 at 19:34
  • 1
    If its important that your application prints "to the last pixel" on a certain printer, it **requires** some level of control over that print queue (driver used as well as settings). Otherwise, forget it. – Kurt Pfeifle Jul 30 '10 at 19:48
  • 1
    Ubuntu is using CUPS for printing. If your PCL output from Ghostscript fulfills 2 conditions: (1) it is at all printable on the target printer; (2) it contains the PCL page image in exactly the required size -- then you could send it with the `-o raw=true` option, bypassing the CUPS filtering chain and shunning the PPD option injection by CUPS into the print data stream. (`lpr -p yourprintername -o raw=true /path/to/A4_300.xxx` -- you may as well use `lp -p...`, btw...) – Kurt Pfeifle Jul 30 '10 at 19:53
  • Does Adobe PDF viewer bypass the lpd then? Can I do the same? I'd be fine fiddling with bytes being sent to /dev/lpN, but these seem to be networked printers and I have no idea how they're connected. The internals of CUPS are a mystery to me that I'd rather not have to explore. – Carl Smotricz Jul 30 '10 at 19:54
  • I suspect the PCL would be good to go if I got it through unmangled, so I'll definitely be giving `-o raw=true` a shot. Heh, what's the use of having GS create printer-specific output if I'm gonna let the printer driver fiddle with it? – Carl Smotricz Jul 30 '10 at 19:57
  • 1
    It's been a looooong time since I've used Linux at all, let alone a recent AcroRead on Linux. It's not ruled out that Adobe bypasses the print system (very likely CUPS in this case, not LPD), but I think that is unlikely. Since they need to direct their print output from Reader (which will definitely be PostScript, not PCL) to one of the system's print queues, the way they could do it is by adding the `-o raw=true` or `-oraw` or `-o raw` somewhere to their print command. [And even more unlikely is that you used a PDF-consuming printer, which Reader auto-detected and fed with raw PDF...] – Kurt Pfeifle Jul 30 '10 at 20:02
  • 1
    GS is **NOT** creating printer-specific output. It's creating generic output. What's dubbed "printer-specific" usually includes fine-tuning commands to staple the output, draw paper from a certain tray, fold the sheets, and what-not. Such special features usually will only work for a specific model, once they're part of the print data stream. Ghostscript doesn't do that (not with the gs commands outlined above). Instead it creates a generic borderless PCL page image -- but in your special case this is what matches your requirements exactly, since you don't need my mentioned bells'n'whistles. – Kurt Pfeifle Jul 30 '10 at 20:09
  • Still struggling with this stuff, but I got a wealth of useful info from you, so here's my acceptance. Thank you! – Carl Smotricz Aug 02 '10 at 23:30