If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
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). 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.
Why Windows clients have a printer driver installed
The filtering system on a CUPS server accepts plain text, PostScript, PDF, JPEG, PNG, and a few other graphics formats. Normally, the filtering system on a CUPS print server cannot convert Microsoft Office documents or other proprietary formats into printer-specific data because an appropriate filtering program is not available.
When filtering would take place as usual on a CUPS server, then a pre-filtering process into PostScript (or one of the other accepted formats, e.g. PDF) would have to be done on Windows client systems before they can print via a CUPS server.
Usually when Windows clients print to a CUPS server, it is done the same way as when they print to a printer share on a Windows print server. This means that Windows clients run the specific driver for the printer also when printing to a CUPS server. The advantage is that application programs on the Windows clients have all printer-specific options of the printer-specific driver available for the user (Linux application programs use PPD files for this purpose, see Concepts printing).
Using Samba and CUPS
Each print queue on the CUPS server must have a matching SMB printer share so that the Windows client systems can send their printing data as usual to a printer share via the SMB protocol. These SMB printer shares are provided by Samba.
This way Samba gets the printing data from the Windows clients via SMB protocol and then Samba forwards it to the CUPS print queue and finally the CUPS printing system forwards it to the printer.
Those successive forwardings from Windows via Samba and CUPS to the printer can cause some delay until the printer starts to print compared to when printing from Windows to a printer which is directly accessible by the Windows system.
Enforce "raw" printing
When Windows clients run the printer-specific driver, they send printer-specific data.
There is no reliable working automatic way to detect whether data which is sent to CUPS is printer-specific data (which should be sent directly to the printer) or data which must be filtered to get printer-specific data. For example when it is a PostScript printer, its printer-specific data is PostScript but by default PostScript data is filtered by CUPS (cf. "PostScript: The traditional printing data format" in Concepts printing).
Therefore when Windows client systems send printer-specific data, the CUPS server must be forced to send the data directly to the printer and not attempt filtering what is already printer-specific data.
This is called "raw" printing. CUPS can be forced to do raw printing by using the "-o raw" switch in the printing command ("lp -d queue_name -o raw").
Samba has by default the following option in /etc/samba/smb.conf to enforce raw printing:
cups options = raw
This way, Samba, which gets the printer-specific data via SMB, forwards it in raw printing mode to the print queue so that CUPS sends it directly (without additional filtering) to the printer.
There are some alternatives to the above described usual way which are only mentioned here but not described in detail:
Send data via LPD protocol or IPP
Windows client systems could be configured to send their printer-specific data, not as usual to a printer share via SMB, but directly to a CUPS print queue via LPD protocol or IPP. In this case the Windows client systems access the CUPS print queue as if it was a network printer (i.e. a printer which is directly accessible via network). If all Windows client systems are changed this way, there is no need for Samba to print to a CUPS server.
Via LPD protocol to a CUPS print server:
Windows can usually send print data also via LPD protocol. In Windows the LPD protocol might be called "LPR". See your Windows documentation how to set up printing this way for your particular Windows version. The host name or IP address of the CUPS server and the CUPS print queue name are needed to set up printing via LPD protocol.
On the CUPS server the cups-lpd (the daemon that accepts data via LPD for CUPS) must run. Up to CUPS 1.7.5 cups-lpd is started via xinetd. Since CUPS 2.0 cups-lpd can also be started by systemd via appropriate systemd unit files. For additional information see "man cups-lpd" and SDB:CUPS in a Nutshell.
You can enforce raw printing for the cups-lpd when xinetd is used in the configuration file /etc/xinetd.d/cups-lpd via this entry:
server_args = cups-lpd -o document-format=application/vnd.cups-raw
With systemd the cups-lpd setup is different.
All data that has the MIME type application/vnd.cups-raw is not filtered but is sent directly to the printer. This means that all data for all CUPS print queues which is sent via LPD protocol is printed in raw mode. If raw printing via LPD protocol should not happen for all CUPS print queues, the above entry cannot be used. Instead additional raw queues must be used, see below.
Via IPP to a CUPS print server:
Nowadays Windows versions can usually send print data also via IPP. In Windows IPP might be called "HTTP". See your Windows documentation how to set up printing this way for your particular Windows version. The URL/URI to access a queue "funprinter1000" on a CUPS server "server.domain" is like (note the "/printers/" part which is mandatory on a CUPS server):
When HTTP is used, the IPP port 631 may have to be specified:
Usually something like a "raw" printing option cannot be set in the Windows setup for printing via IPP/HTTP. In this case the only reliable way to enforce raw printing on the CUPS server is to create an additional raw queue for each printer and use the raw queue when printing from Windows.
To set up a raw queue via YaST, select or enter "Raw Queue" when searching a driver for a manufacturer/model and when you use the CUPS web frontend, select "Raw" as the printer's make.
Filtering on the CUPS server
When filtering should take place on the CUPS server, a pre-filtering process into PostScript must happen on Windows client systems (see above). This is done with PostScript drivers for Windows. Regarding PostScript drivers for Windows you may have a look at the cupsaddsmb man page ("man cupsaddsmb") or the CUPS 1.4 documentation at http://www.cups.org/documentation.php/doc-1.4/man-cupsaddsmb.html