Hello, On May 29 12:02 James Knott wrote (excerpt):
Actually, in the corporate world, it's quite common to allow employees to add/delete printers. That was certainly the case when I worked at IBM and also with the insurance company I've been doing some work
Do you really mean it as follows: "In the corporate world, it's quite common to allow employees to add/delete printers in the corporate network which are used by all employees in the corporate network." Or do you probably mean it as follows: "In the corporate world with a Windows-like printing environment, it's quite common to allow employees to add/delete printers on their own workstations so that the employee can submit print jobs from his own workstation to the corporate print server." Could you provide some more details about the printing environment when you worked at IBM and also in the insurance company. In particular: Was there a CUPS server as corporate print server? I assume in both cases it was a Windows-like printing environment. In this case printers must be usually set up on each individual client system so that the client system can submit print jobs with printer-specific data to the corporate print server. See http://en.opensuse.org/SDB:Printing_via_SMB_%28Samba%29_Share_or_Windows_Sha... ----------------------------------------------------------------- Printing via SMB (Samba) Share or Windows Share ... When a printer is addressed by a Linux host by means of the SMB protocol, this is merely for data transfer. The SMB host does not convert the print data from the applications (e.g., PostScript) to printer-specific data. Therefore, the filtering must take place on the Linux host, which requires a complete print system on the Linux host. A queue with filtering must be set up on the Linux host. After the data is filtered, the queue sends the printer-specific data to the SMB share. The SMB share receives the printer-specific data and forwards it to the printer associated with the share. ----------------------------------------------------------------- (therein you can replace "Linux host" with "any client system") and see http://en.opensuse.org/SDB:Printing_from_Windows_to_Linux ----------------------------------------------------------------- Differences in Printing between Windows and Linux When printing via network with Windows, the most usual case is for the client system to run a driver for the printer which converts the original data (plain text, Microsoft Office documents, or other proprietary formats) into printer-specific format and then send the converted data via network to a printer share on a Windows print server via the SMB protocol. The print server then sends the printer-specific data to the printer. Usually the Windows print server does only the spooling (plain data buffering and transfer to the printer device). The filtering (conversion into printer-specific format) is done on the client system, so printer drivers must be installed on the client systems. When printers are added or replaced, users must install the matching drivers on their laptops or workstations before they can print. Or an automatism installs drivers automatically from a Windows print server on the client systems - provided the users of the client systems like it when an automatism installs software on their laptops or workstations which means that the users must trust such "foreign" software ("how to hijack laptops of innocent guests when they like to print in our environment"). With UNIX/Linux printing, client systems send the original data (plain text, PostScript, PDF, or JPEG) to the CUPS print server, specifically to a print queue via the IPP protocol. The CUPS server then runs a driver for the printer which converts the data into printer-specific format and sends the converted data to the printer device (see Concepts printing http://en.opensuse.org/Concepts_printing). The CUPS server does both the spooling and filtering. This means that client systems don't need to know about differences in printer models and don't need printer-specific drivers. The CUPS server handles the specific details of the printer hardware. The advantage is that end-users can connect laptops and desktops to a network where a CUPS server is running, run their own cupsd on the laptop or desktop, and print immediately. For additional detail, see "Intrinsic Design of CUPS for Printing in the Network" at SDB:CUPS in a Nutshell http://en.opensuse.org/SDB:CUPS_in_a_Nutshell ----------------------------------------------------------------- Finally it really helps to read the wiki page which is especially set up for this kind of discussion: http://en.opensuse.org/openSUSE:Security_use_cases in particular: ----------------------------------------------------------------- Using a remote printer Usecase: Jana takes her laptop to her office and wants to print on one of the office printers. If there is a CUPS server in the office network that advertises its printers via so-called "CUPS Browsing", the cupsd on the local system (if the ports for CUPS are open in the firewall on the local system) would recognize the printers so that there is nothing to set up for the user on her local system. Printing in a Windows network: Usually this means to access a printer device via a SMB printer share. In this case, the local (client) system must usually submit ready-made printer specific data to the SMB share. Therefore, on the client system, a printer driver must usually run and that means the user must usually add a new local printer on her local system for printing in a Windows network. ----------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org