Comment by Adaptive
10 years ago
I've noticed that printing is still one of the poorest UX aspects of *nix/OSS and regularly seems to suffer from errors so egregious that they can only be attributed to OSS devs not dogfooding these features. I'm assuming they just don't print much (I mean, we ALL print less than 20 years ago, but all the more reason to test these features which, when you need them to work you REALLY need them to work).
Perhaps you're thinking back to the days of manually configuring CUPS?
Any recent printer I've used has just been plug it in and hit print. A better experience than Windows in terms of included drivers and bonjour support too.
No, you've simply been lucky.
I can say my experience matches the above posters as well. Printing in Ubuntu works better than OSX and Windows for the 4 different printers I use regularly.
3 replies →
I agree completely. I set up a relative with Linux Mint KDE 17.3 a couple weeks ago and even I was surprised at how easy it was to set up the two printers he wanted to use: one was an old 2003-vintage LaserJet 1012 personal-sized laser printer with USB, the other a newer (I'm guessing 4yo) HP color inkjet of some kind that was WiFi-connected. For the first, I just plugged in the USB cable and a print queue was immediately and automatically set up; I didn't have to do anything. For the latter, I just went into the printer configuration utility, let it search the network, it found the printer and told me its model name/number, then I selected the appropriate driver and printed a test page. No driver downloads, no problems.
By contrast, I had a contract job a year or so ago at a large company where I was given a Win7 laptop and tried to connect to a big Ricoh laser printer. I spent hours messing around with driver downloads trying to get that to work. I finally had to call IT and they sent someone over, and he couldn't get it to work either; he finally found some crazy work-around which I've totally forgotten the details of now.
The only real problem I see with printing on Linux now is that, sometimes, there's multiple CUPS drivers for the same printer (foomatic, hpijs, Postscript, etc.), so it won't automatically pick one and it's not clear which is the best so you might have to just try one and see if it works. Most likely, they all work, but some might have additional features. HP printers are probably the best, though, since they seem to explicitly support Linux (such as with their hpijs drivers). If all printer makers had this level of support, and they cleaned up the redundant/competing drivers, there wouldn't be complaints.
CUPS is better, no doubt. And from a sysadmin perspective CUPS is great, but there are still crazy gotchas.
Part of this is the byzantine config of network discovery, CUPS, driver sources, etc. A big part of the problem is the pieces may be there but distros have done a mediocre job getting everything together on this in the best way for the user.
One of these days, someone may give me a credible explanation of why printing involves a systemwide daemon, but I kind of doubt it. I'd love to see a rearchitecting of the whole mess such that the whole print daemon runs in in a sandbox with user privileges.
How would you avoid having a common print queue, when all the documents can't fit in the printer memory?
It's been a while since I bought a printer that connected via any means other than Ethernet or Wifi, so the printer already needs to manage its own queue regardless of what the client computers do.
For printer that attach directly, there could be a daemon that arbitrates access and handles accounting or the system could simply allocate the printer to the logged-in user. For directly connected printers on multi-user systems, you'd want a real daemon, of course.
For daemons that mediate access, IMO the arbitration and accounting should be split from formatting and rasterization (if needed). For accounting and arbitration, the right way to do it is to speak something like Printer Job Language. I actually wrote a daemon like this years ago. I wonder if I still have the code. It actually counted pages regardless of how they were submitted.
Anyway, for a normal desktop machine, I think that the system daemon is silly these days.
3 replies →
Have the printer act as a server to which each of the sandboxed print queues talks directly, seeking permission to send data, and let the printer handle flow control.
Not saying this is necessarily a good idea, but it avoids a system-wide print queue, all you need at the system level is a service locator to let you know where the printer is that you need to contact.
5 replies →
In my experience it is the exact opposite. My Linux computers are always able to quickly connect and print to any printer I point them towards. I have never had as many problems as I have had when using Windows or OS X.
I can't say it's been any "easier" to connect to my Brother MFC-J4420DW on Fedora as it is on Windows, but it's no harder. Download the installation script from Brother, run it, it asks me for the hostname of my printer and I'm up and running.
> Download the installation script from Brother, run it, it asks me for the hostname of my printer and I'm up and running.
But this is already sounding archaic and difficult isn't it? Just download and run an installation script? Give it the host name? No way a nontechnical user is going to be able to do either of those things.
Why doesn't the printer just appear like it does on my Mac? I'm not even sure what my printer's host name is so I wouldn't even be able to do that step myself!
9 replies →
I just got a Brother LED printer: the HL-3170CDW. Very nice printer. Works fine on with one 64 bit Win-7 system. With another system, a 32 bit Win-7, it won't work at all. Printing a test page fails with 0x000000D, and no application can print. (The printer is seen, and its status can be monitored and so on, but Windows just won't print!) This is whether or not it is on Wi-Fi or USB. I tried three versions of the drivers, and every possible remedy: I applied a Microsoft HotFix for repairing Win7/SP1 systems. I ran sfc /scannow. I run chkdsk /F on the C: drive. (The machine is an older system, but the SMART info shows that the drive is in perfect health: low temperature, no bad sectors.) I reset Windows Update and got it into a sane state. I went through every possible trouble-shooting procedure that could be googled up that could be related to the issue. Fixed things in the registry according to various steps. No dice.
In my experience printing in Linux has been pretty solid for at least the last 5 years or so. CUPS is CUPS, drivers are plentiful and one apt-get away, UIs get better.
Of course I'm limited to occassional document or a few tickets.