Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
May contain nuts.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                     

Driverless Network Printing Protocol

Clients shouldn't need printer drivers
  (+1, -2)
(+1, -2)
  [vote for,
against]

When using a Windows box as a print server, the client must have the printer driver in order to use the printer. This makes it hard when using a Linux/BSD/Whatever box as a client, because most printer makers still don't have linux drivers, and not all printers have free software drivers. I propose a system by which the client only needs to have a PDF processor. It would work like this:

- Client sends a request to the server
- Server sends a list of available printer driver options (resolution, feeder, duplex printing) in a universal format. The client's UI interprets the options list and displays the options to the user.
- User selects the options they want and click Print
- Client sends the selected options to the server, as well as the document to be printed, as a PDF or some other open format.
- Server reads the PDF, sends it along with the printing options to the printer driver as if the PDF were being printed straight from the server computer.

The advantages of this would be that as long as the server computer supports the printer's driver, any client that can use this protocol can print through it. It could be implemented by server software running on the server, and a multiplatform driver for the protocol running on all the clients.
-----, Dec 17 2006

Print from Unix to Windows http://www.frogmore...nfigure-lpdsvc.html
Setting up LPD -- the printserver [TerranFury, Dec 19 2006]

Printing using LPR in Windows http://www-ssrl.sla...s_lpr_printing.html
Setting up LPR -- the client side [TerranFury, Dec 19 2006]

[link]






       Sounds a lot like Postscript. Postscript makes a printer a little bit more expensive.
jmvw, Dec 17 2006
  

       As far as I can tell, this amounts to all printers implementing the same driver protocol. ("a universal format" in your write-up).
jutta, Dec 17 2006
  

       You both have misunderstood my idea. I'm describing a system where the computer acting as the print server is the computer running the driver. I'm not trying to change the way a computer communicates with a printer, I'm just trying to change the way a computer sends data to a print server computer. The way I'm describing, a printing client does not need to know how to talk to the printer, it just needs to be able to send the data to the print server computer in a document format the server computer can understand. That way, only the server needs to know how to talk to the printer.
-----, Dec 17 2006
  

       You're suggesting an abstraction layer that removes any printer-dependent differences. For example, CUPS and Ghostscript adopt a not dissimilar approach, whereby all the device-specific differences are embodied within the CUPS driver collection. My cheapo Samsung laser printer is connected to a Linux machine running CUPS and Ghostscript, and from another platform it can be set up as if it were an old Apple Laserwriter 600 (a PostScript printer) (which of course it isn't, but it acts like one with Ghostscript in the loop).
Ian Tindale, Dec 17 2006
  

       Ian, that's pretty much what it is. However, Ghostscript only supports certain printers. Having a system that translates postscript to the printer's protocol using the printer's native driver itself is what I'm going for.
-----, Dec 17 2006
  

       Kind of like TWAIN for scanners?
BunsenHoneydew, Dec 19 2006
  

       Yeah, I was about to suggest that this is already baked being that any post script printer will do exactly that.
Jscotty, Dec 19 2006
  

       Solution!! Do it Unix-style, in Windows. Use LPD on your (Windows) server, and LPR on your (Windows) client. This adds exactly the abstraction layer you're talking about, right? Do it with Windows Print Services for Unix.   

       Check out the links. Tell me if I'm getting this right.   

       This idea is 'baked' insofar as the building blocks seem to be available to put this together pretty easily, but it's novel in that I've never seen an I.T. department do it this way -- with Windows boxes talking to each other 'nix-style.   

       So, I agree completely that computers shouldn't need drivers for network printers even if you are using proprietary print drivers on the server, and I think we've got a way here to achieve that.
TerranFury, Dec 19 2006
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle