h a l f b a k e r yNaturally, seismology provides the answer.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.
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]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
Sounds a lot like Postscript. Postscript makes a printer a little bit more expensive. |
|
| |
As far as I can tell, this amounts to all printers implementing the same driver protocol. ("a universal format" in your write-up). |
|
| |
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. |
|
| |
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. |
|
| |
Kind of like TWAIN for scanners? |
|
| |
Yeah, I was about to suggest that this is already baked being that any post script printer will do exactly that. |
|
| |
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. |
|
| |