If I have a large file to print, on Linux it can takes ages spooling - hours even - where on Windows it can be printing in seconds. I've noticed this many times over the years, on all types of printer I've had use of.
(Large typically means graphical, eg I tried printing a 2 page A3 PDF as my Windows PC was offline, and I managed to rebuild my Windows PC, transfer the file and be ready to print before I hear a peep from the printer, and on cancelling the Linux print, Windows had the printer clunking away a few seconds later.)
Is there a good reason for this? Is it just me?
On Wed, 2020-08-19 at 10:26 +0100, Mark Rogers wrote:
Is there a good reason for this? Is it just me?
It isn't just you. I've transferred files to the wife's Mac to print them before now, because it's quicker than waiting for my Mint box to print them. Also, every so often I come across stuff that won't print at all from Linux, and I copy that, ditto. (Linux Mint 19, HP LJ2055dn) It was even worse in the days when I had a LJ5 - sometimes it took 10 or 15 minutes per page to render the output. My personal theory (for which I have exactly no evidence) is that something (WebKit, maybe?) generates *terrible* Postscript. BTW, Linux prints plain text just as quickly as anything else, which is a tiny data point for my theory.
I've not had cause to print anything recently, but when I did, none of the printers I've had (all HP) were slow. My Linux machines have been slower to boot though. (The last was glacial but I think there were other reasons for that.)
Bev
On 19/08/2020 11:20, Huge wrote:
On Wed, 2020-08-19 at 10:26 +0100, Mark Rogers wrote:
Is there a good reason for this? Is it just me?
<snip>
On 19/08/2020 10:26, Mark Rogers wrote:
If I have a large file to print, on Linux it can takes ages spooling - hours even - where on Windows it can be printing in seconds. I've noticed this many times over the years, on all types of printer I've had use of.
(Large typically means graphical, eg I tried printing a 2 page A3 PDF as my Windows PC was offline, and I managed to rebuild my Windows PC, transfer the file and be ready to print before I hear a peep from the printer, and on cancelling the Linux print, Windows had the printer clunking away a few seconds later.)
Is there a good reason for this? Is it just me?
Well......
It depends. It can be slow. It's certainly complicated!
A lot of the time, Linux writes print jobs are translated either to graphics or to postscript which can then be sent over to the printer - these can be huge so can take an age to transfer.
It also depends on your config. I have a linux server running a cups server. My printer is connected to this via USB. I have 2 "devices" set up on my server, both pointing to that printer. One is a "Raw" device - accepts stuff and sends it straight to the printer - this is shared with my network. The other is a normal appropriate printer driver for the printer. If printing on my server, I print to the "Normal" printer.
On my laptop, I have installed a local printer driver, but I get it to send to my network's shared "Raw" device. Why? Well, printing used to "just work" as they say, but something went wrong and I investigated. I used to have the local printer driver print to the server's printer driver, but what this was doing was taking a (say) LibreOffice document, changing it to graphics or postscript (or whatever the printer directly understands), then sending this document to the server's version of cups, which was then sending it through it's own print-processing driver, where it was again transferred into graphics, and then it was sent to the printer. From what I gathered, this 2nd step was superfluous leaving me with 2 options/
Laptop have a Raw device, Server has a printer-driver device. Laptop doesn't process and just sends the files to the server where they're processed.
Laptop has a printer driver, server has a raw device. Laptop processes the document and sends it to the server which just passes it on.
The 2nd approach worked best for me. The Laptop connects to the server's raw device with an IPP URL ipp://192.168.1.1:631/printers/PRINTER_NAME_RAW?waitprinter=false&waitjob=false where 192.168.1.1 is the server IP, 631 is the CUPS port PRINTER_NAME_RAW is the name of the raw printer device.
Then there's another wrinkle. By default CUPS waits until it has received the whole file and for the printer to be online before spooling to the server, and sending the print job. Windows does the opposite and so seems to print faster. This is what the "?waitprinter=false&waitjob=false" parameters do - sends the file to the server's cups even if the printer is off-line, and start printing IMMEDIATELY, without waiting for the whole file to be transferred.
My setup is hampered by GNU's printer utility and cups being determined to try and auto-discover network printers (and to a certain extent, Firefox and Thunderbird doing the same). These add auto-discovered printers to print dialogs and the Printers utility. Without fail, none of these work for me and I can't configure them, becuase they are ephemeral and are re-detected on each log in. (They're detected partially by bonjour/zeroconfig/dlna. As I need that service for something else, I can't disable it. Wish I could).
YMMV of course. It depends where your printer is and how it is connected to your network. In some ways wireless connection is simpler as you don't have to faff with setting up a network's print sharer. If it's connected to a Windows machine, it's probably shared via Samba. If it's connected to a linux machine, and you want windows to print to it, you may have it shared via Samba as well - this works and I used it for years, but I eventually realised that I had the device shared via CUPS as well, and I could do-away with Samba printer share by using IPP, which I think is the more modern way to go.
So, it can be complicated! I hope this may have helped a bit in explaining ways of speeding things up.
Steve
On Wed, 19 Aug 2020 at 17:59, steve-ALUG@hst.me.uk wrote:
It depends. It can be slow. It's certainly complicated!
That's a decent summary of my experience with printers over the past 30 years!
[.. snip lots of good stuff ..]
Then there's another wrinkle. By default CUPS waits until it has received the whole file and for the printer to be online before spooling to the server, and sending the print job. Windows does the opposite and so seems to print faster. This is what the "?waitprinter=false&waitjob=false" parameters do - sends the file to the server's cups even if the printer is off-line, and start printing IMMEDIATELY, without waiting for the whole file to be transferred.
This might well be part of it. (Given that some of the stuff I'm trying to print is going to take the printer several minutes per sheet once it starts, as long as the spooling is faster than the printing it makes sense to be sending immediately). But it's not the whole story - I've certainly had situations where it could be 30 minutes without so much as a peep from the printer but my Linux box is apparently still working on it, whereas even the slowest prints are maybe 5 mins per sheet start to finish via Windows.
YMMV of course. It depends where your printer is and how it is connected to your network.
Fair point, i should have started with that!
All my printers (2 at work, 2 at home currently, but all the ones that have been in their places before them for as far back as I can remember) have been direct network (cabled), ie my PC/laptop is talking to the IP of the printer directly without an intermediate Linux or Windows box.
What is the best way to see "inside" the printing process and see what is taking the time?
Based only on the times taken, it *feels* like Windows is sending printing commands (eg PCL or something bespoke to the printer via the Windows printer driver) whereas the Linux box is turning everything into a high DPI bitmap and then trying to manage that - ie one is sending vastly more "data" to the printer than the other for the same desired outcome.
On 21/08/2020 08:21, Mark Rogers wrote:
On Wed, 19 Aug 2020 at 17:59, steve-ALUG@hst.me.uk wrote:
YMMV of course. It depends where your printer is and how it is connected to your network.
Fair point, i should have started with that!
All my printers (2 at work, 2 at home currently, but all the ones that have been in their places before them for as far back as I can remember) have been direct network (cabled), ie my PC/laptop is talking to the IP of the printer directly without an intermediate Linux or Windows box.
What is the best way to see "inside" the printing process and see what is taking the time?
Not sure. Is Cups installed? I would expect it is. Try web-browsing to 127.0.0.1:631. Check printers. See which printer driver you have installed. Click on one of the print queues, click "show all jobs" - if this shows print jobs it confirms that printing is going via cups. Click back on "Show Active Jobs" to switch back to normal view.
I'd suggest looking at cups configuration info (config files?), looking at printer settings in cups's web interface and looking at Linux's printer settings in whichever flavour of Linux you have
e.g. sudo system-config-printer on gnome based distros e.g. *buntu.
Based only on the times taken, it *feels* like Windows is sending printing commands (eg PCL or something bespoke to the printer via the Windows printer driver) whereas the Linux box is turning everything into a high DPI bitmap and then trying to manage that - ie one is sending vastly more "data" to the printer than the other for the same desired outcome.
Try a different printer driver too. Is there one on the manufacturer's website? Also, sometimes there is more than one printer driver that works with a specific printer.
I'm sure a bit of judicious googling with "Slow Printing Linux PRINTER NAME" or "Linux Printer Driver PRINTER NAME" I'm sure there's lots of info out there about fixing Linux printer problems.
That's about all I can suggest. Good luck.
Steve
On 22/08/2020 22:23, steve-ALUG@hst.me.uk wrote:
That's about all I can suggest.
Oh!
If you're connecting to the printer's IP directly, see what methods of connecting it has. It could have IPP and/or Samba. You could try swapping from whichever you are using to the other. Also, the printer will have some config settings on it which you could try fiddling with.
Steve
On Sat, 22 Aug 2020 at 22:23, steve-ALUG@hst.me.uk wrote:
Not sure. Is Cups installed? I would expect it is. Try web-browsing to 127.0.0.1:631. Check printers. See which printer driver you have installed.
Sorry for so long getting back to this, I've been out of the office where I wanted to test.
I just sent a 2 page PDF to my Samsung CLP-680.
CUPS shows the print job. Size 204k, current status "Spooling job, 45% complete." (the job was started over 5 minutes ago).
The web interface tells me the printer config is: Connection:dnssd://Samsung%20CLP-680%20Series%20(SEC842519116DA6)._printer._tcp.local/ Defaults:job-sheets=none, none media=iso_a4_210x297mm sides=one-sided
(Not sure if that is useful.)
One of the things I never quite understand is how to pick which printer connection to use. For this printer I currently have these options: Samsung CLP-680 Series (SEC842519116DA6) (Samsung CLP-680 Series) Samsung CLP-680 Series (Samsung CLP-680 Series) Samsung CLP-680 Series (SEC842519116DA6) (Samsung CLP-680 Series) Samsung CLP-680 Series (driverless) (Samsung CLP-680 Series)
(Two of which I note are identical.)
The driver is "Samsung CLP-680 Series (PS)".
Oh, and since I started writing this the job has finally printed the first page and maybe 80% of the second and thrown a memory error (at the printer end). Took maybe 10 minutes to reach that point.
The only other option given for this specific model is "Samsung CLP-680 Series, driverless, cups-filters 1.27.4". Switching to that driver sped things up considerably - from print to completion in seconds, as I'd expect from Windows.
So that seems like a success to me, but why? I'd be very surprised if I ever picked anything other than defaults when setting up the printer.
(Thanks for your help making this printer usable on Linux!)
On Wed, 2 Sep 2020 at 09:33, Huge huge@huge.org.uk wrote:
There's your problem. Right there. Just be glad it hasn't burned your house down. Throw it away and buy something, anything, else. Not made by Samsung.
My initial problems were with my Brother A3 printer but playing with the Samsung is cheaper.
And I think the Samsung is actually an HP under the Samsung brand.
On Wed, 2 Sep 2020 09:29:58 +0100 Mark Rogers mark@more-solutions.co.uk wrote:
The driver is "Samsung CLP-680 Series (PS)". [...] The only other option given for this specific model is "Samsung CLP-680 Series, driverless, cups-filters 1.27.4". Switching to that driver sped things up considerably - from print to completion in seconds, as I'd expect from Windows.
So that seems like a success to me, but why? I'd be very surprised if I ever picked anything other than defaults when setting up the printer.
Well, I can't be sure without dissecting your system but I suspect the "PS" indicates that the PDF is being converted to PostScript and then that sent to the printer. I can't remember what pdf2ps and similar likely converters do about things like drawings, images and fonts. Quite possibly some modest PDF files turn into really big PS ones, big enough to take a long time and overflow available memory.
I suspect the "driverless" option just sends the PDF to the printer and lets the printer decide what to do with it. https://www.cnet.com/products/samsung-clp-680nd-printer-color-laser-clp680nd... says that printer can handle versions of PCL, PDF and PostScript natively, as well as SPL-C(?). So probably now only the PDF is being sent over there and no spooling or conversion is happening on your computer, which is much faster. The main downside is that if you find a way to send it a JPEG not converted to PDF or similar, it may spew pages of gibberish until you hit the power switch or run out of paper (BTDTGTTS...).
The default suggestion is probably picked by a general rule, such as "any driver you downloaded, else the one with the longest list of accepted input formats". It may not be correct in every case, such as if your printer can handle several formats natively.
Oh and as I found some drivers on support.hp.com, I suspect you are right about it being a HP inside!
Hope that explains,
-
Bev Nicolson -
Huge -
Mark Rogers -
MJ Ray -
steve-ALUG＠hst.me.uk