PDF Printing follies

Beeblebrox

Beeblebrox

All righty!
I have done a quite of bit of reading, and must say that I am now thoroughly confused. My problem is that printing PDF files is very slow and problematic (I can print text, office, etc easily).

I have an HP LaserJet 2100tn with postscript capability (full specs here). The printer also has appsocket card (older jetdirect model with small RAM 6-8).

My system has print/cups as spooler, print/gutenprint and print/ghostscript9 installed. I also have a Virtual PDF Printer set-up which I use for conversion of html pages. I select this device directly from a web browser and crete the PDF - this process is fairly quick and seems to work smoothly.

I use document viewers when printing a PDF file to the HP2100 and depending on the ppd file I use I get one of two results:
1. 2100-CUPS+Gutenprint v5.2.7 -> The pc works for a long time (it once worked for 1.5 hours, I could not take it anymore and stopped the process) then sends the page to be printed in a short burst to the printer and we get a correctly formatted page.
2. 2100 Series Postscript -> the printer blinks its light for hours and we may or may not get a correctly formatted page; in the mean time the printer cannot accept other jobs.

Sometimes the second page can be an error message with the remainder of the pages having been dumped. I usually print 2 PDF pages in landscape mode on 1 paper or sometimes 4 to 1.

In search for a solution I have also tried:
- Foomatic drivers, also separately HPLIP as the spool
- From the cups web site this PPD: ppd/hp/en/hp2100_4.ppd.gz, but same result as postscript.
- This thread http://forums.freebsd.org/showthread.php?t=3646&highlight=cups+pdf+ghostscript+gutenprint has quite useful information, but I could not solve the problem of long processing time.
- I also have [print]print/cups-pdf[/print]installed. Maybe I have too many ports installed which keep passing their tasks to one another and thereby sucking up time?

I must be doing something wrong or have omitted a setting that should speed things up. This post on another forum describing how to reduce the size of the PDF file probably has some relevance to the issue, but the method/steps described therein to get the result is silly.
 
I must have posted as-about-the-same-time-you-did. I made some corrections to my posts but was late responding because I was busy with finding something which, in the end, really mattered more to me: an MSG song stuck in my mind. I could not find it, but here are some links instead:
http://www.youtube.com/watch?v=bWkITJ0hdWo&feature=related
and then http://www.youtube.com/watch?v=B8qlh8nMErU&feature=related
but still not the piece stuck in my head.
EDIT: found it - http://www.youtube.com/watch?v=w9Oc6GbV1mg
 
To rule out a problem with the printer's PostScript, use pdf2ps(1) as jb_fvwm2 suggests, but bypass CUPS by sending it directly to the printer. Assuming the printer is connected to the network:
# pdf2ps test.pdf - | nc lj2100 9100
where lj2100 is the DNS name or IP address of the printer.
 
@ wblock: Yeah, that command was not liked by anyone!
- The printer spat out an empty page and went to red, then kept humming for a long time.
- Command line output:
Code: 
# sudo pdf2ps test.pdf - | nc 192.168.1.9 9100
GPL Ghostscript 9.02: Unrecoverable error, exit code 1
and then just hung until <ctrl> C
 
FWIW, I just print from xpdf (using CUPS' lpr) and it works for me. Yes, I have a different printer, with it's own drivers (the printer is not Postscript).
 
- I created a virtual_PS_printer in CUPS using the cups-generic-ps PPD. When I print a web page through virtual_PS_printer, the page is converted to a PS file having PDF extension within an acceptable time.
- When I try to print the PS file from a PDF viewer, I got the same problem (long processing). Then I got:
$ gs -dSAFER -dNOPAUSE -sDEVICE=HP_LaserJet_2100 -sOutputFile=\|lpr Midori*
Code: 
GPL Ghostscript 9.04 (2011-08-05)
[U]Unknown device: HP_LaserJet_2100[/U]
Unrecoverable error: undefined in .uninstallpagedevice
Operand stack:       defaultdevice
What?? Seems like print/ghostscript9 does not like talking to CUPS.
$ lpstat -d
Code: 
system default destination: HP_LaserJet_2100
 
I'm so confused I can't even describe the problem anymore

1. @tingo: Thanks for the link. I tried the driver there (HP-LaserJet_2100-pxlmono.ppd). No change and even worse - must be other problem with my setup.
2. Printing directly from hplip gives:
Code: 
Print command failed with status code 1:  lpr -P HP_LaserJet_2100
None of my lpr commands from the cli respond. Result of this work-around (for lp & lpr)
# mv /usr/bin/lpr lpr-old
# ln -s /usr/local/bin/lpr /usr/bin/lpr
Was no more error, but no printout either - like it went to /dev/null.
3. I used a ps file to test pdf2ps as suggested, got a printout after about 15 mins of blinking but almost everything about the printed pages was wrong.
4. Related? I cannot import pdf nor ps files to abiword or libreoffice. The import either hangs or displays only unreadable characters expanded to many pages (20 pages instead of 1).
5. Ghostview does not work correctly (only shows 1st page, no controls respond), but gsview does.

I have messed around with this so much that I can't even print text files anymore! I think the problems are separate:
a- cups/lpr/driver problem
b- ps/pdf processing length
I think I need to de-bug these issues separately.
 
some progress

Finally got my head together and started sorting it out.

* pdf-> ps conversion has problems with ghostscript (pdf2ps). It takes very long, uses a lot of mem & swap, and the file size is very large. poppler & xpdf do a much better job (pdftops) imho and is "blindingly fast" in comparison to gs. Embedded images are low resolution, but finding that button was not of immediate concern. pdftops also converted a pdf file without any complaints, that pdf2ps refused by claiming the pdf was faulty.

* a direct command to lp and lpr do not work when cups is installed because it has to be /usr/local/bin/lp instead of /usr/bin/lp (the default).

* WHERE I AM NOW: printing through cups just blacks out (nothing happens, not even err msg). Same for this command:
# /usr/local/bin/lp filename.ps
This works, however other options passed about orientation or number-up have no effect (just prints 1 per page).
# /usr/local/bin/lp -o raw filename.ps

What is this about?
 
somewhat ironic:
home.nuug.no/~peter/pf/en/pf-firewall.pdf

Description of the RAW print solution is valid regardless of which pdf/ps, however. That is a consistent error.
 
I've had similar problems with almost any constellation on my system including eog. The only thing that worked reasonably well was OpenOffice. I was able to fix most of these issues by reverting to ghostscript8. Now there are only some rare cases of PDF files that fail to print. Most of these are probably owed to crappy PDF generation and won't print on any of the Windows systems I have at my disposal, either.

The aforementioned document printed perfectly well on a Lexmark E232 (Foomatic/pxlmono) and a HP LJ2300 (Foomatic/ljet4) with 2, 4 and 16 pages per sheet. Both printers are used in PCL mode.
 
I currently have an Ubuntu system I was preparing for a friend, so I set up the LJ2100 on it to test. Similar docs printed perfectly (only minor margin problems). This be a strange error.

@fmw:
[using]...(Foomatic/pxlmono) and a HP LJ2300 (Foomatic/ljet4).....Both printers are used in PCL mode
Click to expand...
That is probably my problem with cups. I have tried both foomatic/pxlmono and foomatic/ljet4 (among others) but the filter is maybe not using PCL but ps instead?
The aforementioned document printed perfectly
Click to expand...
Yeah, I can print it too once I convert it to ps and use RAW!!

p.s. nice Eric Idle pic btw!
 
Oh, I went through the same kind of crap, I wound up trying all kinds of applications and exploring the debug capabilities of CUPS in this thread here. This included sending foomatic-rip.ps to all printers in either PCL mode to the laser printers and in whatever the inkjet printer takes to this one (HP 695C :P) which knows no PS whatsoever. Now that I think of it again, it's funny that I didn't try piping the PS output directly to the laser printers...
Anyway, the only way for me to fix this problem really was to revert to ghostscript8. You may want to try it; it doesn't take long to install even from ports.

Oh and BTW, Eric's from the Holy Grail :beer
 
Unfortunately as I expected, switching from gs9 to gs8 did not solve the problem. As I had stated, trying to fix the issue resulted in my breaking cups somehow, such that I am unable to print from libreoffice or even a simple text from gedit. It looks like the print stream just gets dumped or into a black hole as absolutely nothing happens (no err message, no job shows up at the spool, etc).

I think the key here is, this results in the same as above (file is a text message "hello")
$ /usr/local/bin/lp hello
while adding -o raw to the command is able to print (txt, ps, etc).

This leads me to think that the ps layer of cups is damaged and that cups can only receive pcl streams.
 
/tmp or /var/spool full?

Also, check if there's excessive CPU/HD activity after invoking the print command.
 
My /tmp and /var/tmp are mounted as tmpfs(5)() so "becoming full" is impossible. I clean out the /var/spool/cups after every cups testing to prevent contamination during next test.

No cpu/hdd load for lp commands, certainly not for txt files. I neglected to mention in my last post that cups does create a file in /var/spool/cups corresponding to the print attempt be it from cli or gui, but nothing more happens.

EDIT: I think this could be related (printcap):
http://forums.freebsd.org/showthread.php?p=166341#post166341
 
This is not very likely. /etc/printcap is only for the conventional lp/lpr commands, CUPS shouldn't ever look at it. On my system, I've never had to touch it. The next step should probably be to gather debugging info from CUPS - locate cupsd.conf and add or change the LogLevel entry:
Code: 
LogLevel debug
 
I tried that before posting (cups & cups-pdf) - no useful info, no relevant error messages. I'll give it another try though...
 
You must log in or register to reply here.
Back
Top