5.1. Printing

This section describes how to configure printing services in SGD and includes the following topics:

5.1.1. Overview of SGD Printing

SGD supports two types of printing: PDF printing and Printer-Direct printing.

With PDF printing, users print from an application using an SGD PDF printer. The print job must be in PostScript format. The PostScript print job is sent from the application server to an SGD server, where it is converted into a Portable Document Format (PDF) file. The SGD server then sends the PDF file to a PDF viewer on the user's client device, where the file can be viewed, saved, and printed.

With Printer-Direct printing, users print from an application to a printer attached to their client device. SGD does this by cooperating with the lp or lpr printing system on the SGD host and the native printing system on the application server. The print job is sent from the application server to an SGD server. The SGD server then sends the print job to the SGD Client, which sends it to the user's client printer. If the format of the print job used by the application server is different to the format needed by the client printer, SGD converts the print job before sending it to the SGD Client.

PDF printing is usually more reliable and produces better results than Printer-Direct printing.

SGD has two PDF printers: Universal PDF Printer and Universal PDF Viewer.

On Microsoft Windows client devices, the Universal PDF Printer displays the print job as a PDF file in the Adobe Reader, which then prints the PDF file to the user's default printer. The Universal PDF Viewer displays the print job as a PDF file in the Adobe Reader, which the user can then decide whether to print or save.

On UNIX, Linux, and Mac OS X platform client devices, there is no difference between the Universal PDF Printer and Universal PDF Viewer, as the print job is always displayed as a PDF file in a PDF viewer. The user can then decide whether to print or save the PDF file.

SGD uses distributed printing. Print jobs are sent to the SGD server hosting the user's application session. This means that a user's print jobs are distributed across the array, and there are no bottlenecks or single points of failure.

SGD supports printer-direct printing to PostScript, Printer Command Language (PCL), and text-only printers attached to the user's client device. The SGD tta_print_converter script performs any conversion needed to format print jobs correctly for the client printer. To convert from Postscript to PCL, Ghostscript must be installed on the SGD server.

5.1.2. Setting Up Printing

Setting up printing involves the following configuration steps:

  1. Configure application server for printing.

    The required configuration for the application server depends on the application server platform.

    See Section 5.1.3, “Configuring Microsoft Windows Application Servers for Printing”.

    See Section 5.1.4, “Configuring UNIX and Linux Platform Application Servers for Printing”.

  2. Configure the SGD servers for printing.

    See Section 5.1.5, “Configuring an SGD Server for Printing”.

  3. Configure printing to client devices.

    The required configuration depends on the client device platform.

    See Section 5.1.6, “Configuring Printing to Microsoft Windows Client Devices”.

    See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”.

5.1.3. Configuring Microsoft Windows Application Servers for Printing

The configuration required to print from applications running on a Microsoft Windows application server depends on the version of the Microsoft Remote Desktop Protocol (RDP) protocol that is used to connect to the application server. See the following:

5.1.3.1. Configuring Printing for Microsoft RDP 5.0 or Later

SGD automatically creates printer queues in the Windows application session if the application server supports Microsoft RDP version 5.0 or later. This applies to Microsoft Windows 2003 Server and later application servers.

When a user starts or resumes a Windows application, the SGD Client sends information about the client's printers to SGD. SGD supplies this information to the application server and the application server then creates, or maps, the printers in the Windows Remote Desktop Services session. The user sees the printers that are attached to the client device and also the printers that are attached directly to the application server.

To be able to create a client printer in the Microsoft Windows application session, the following must be true:

The printer drivers that must be installed on the application server are as follows:

SGD Administrators can control the SGD printers that are available in Windows Remote Desktop Services sessions. See Section 5.1.3.1.1, “Configuring the Printers Available in Windows Remote Desktop Services Sessions”.

5.1.3.1.1. Configuring the Printers Available in Windows Remote Desktop Services Sessions

SGD enables Administrators to control the printers that are available in Windows Remote Desktop Services sessions. You can configure the printers, as follows:

  • Globally. In the Administration Console, go to the Global Settings → Printing tab.

  • Individually. In the Administration Console, go to the Printing tab for an organization, an organizational unit, a user profile, or a Windows application object.

    If you configure an organization or organizational unit object, this affects all the users in that organization or organizational unit.

    If you configure a Windows application object, this overrides the printing configuration for organization, organizational unit, or user profile objects. The order of precedence for printing configuration is: Windows application → user profile → organizational unit → organization.

You can set the following attributes on the Printing tab.

Table 5.1. Attributes Used to Configure Printing From Remote Desktop Services Sessions

Attribute

Description

Client Printing

Controls the client printers users can print to, either all client printers, the default client printer, or no client printers.

By default, users can print to all their client printers.

Universal PDF Printer

Enables the Universal PDF Printer printer.

Make Universal PDF Printer the Default

Sets the Universal PDF Printer printer as the client device's default printer for Windows applications.

Universal PDF Viewer

Enables the Universal PDF Viewer printer.

Make Universal PDF Viewer the Default

Sets the Universal PDF Viewer printer as the client device's default printer for Windows applications.

Postscript Printer Driver

The name of the PostScript printer driver to use for PDF printing.


Note

Any configuration changes you make on the Printing tab only take effect for new user sessions.

If you make a PDF printer the default printer for Windows applications and SGD is configured to only allow users to print to their default printer, users see two printers in their Windows application session. The user's default client printer and the PDF printer are shown.

To use PDF printing, you must install the PostScript printer drivers you want to use for PDF printing on the application server. Make sure the printer drivers have sufficient features for your users. By default, SGD is configured to use the HP Color LaserJet 2800 Series PS printer driver. The printer driver name entered in the Postscript Printer Driver field on the Printing tab must match the name of the printer driver installed on the application server exactly. Pay particular attention to the use of capitals and spaces. The /opt/tarantella/etc/data/default.printerinfo.txt file contains all the common printer driver names, ordered by manufacturer. To avoid errors, copy and paste the driver name from this file.

Note

If a PDF viewer is not configured on the client device, the PDF printers are not available in the Windows application session, even if a PDF printer is enabled.

5.1.3.2. Configuring Other Microsoft Windows Application Servers for Printing

To print from an Microsoft Windows application server that uses a version of the Microsoft RDP protocol earlier than version 5.0, you must configure a Line Printer Remote (LPR)-compatible TCP/IP printer on the application server. Configure the printer to send print jobs to the primary SGD server in the array. Consult your system documentation for details of how to configure printers.

Note the following limitations:

  • PDF printing is not supported.

  • No multiple printer support. You can only print to the client device's default printer. It is not possible for users to select a printer. If a user needs to print to a different printer, they have to log out of SGD, change their default printer, and then log in again.

  • Print jobs might be deleted. When a print job is transferred from the application server to an SGD server, the user's SGD name is needed to identify which client device to send the print job to. With some versions of Microsoft Windows, there is no direct way to associate print jobs with SGD users. If SGD cannot identify which user has printed a particular job, the print job is deleted. This might happen, for example, if two users log in to the application server with the same name.

  • Distributed printing is not available. All print jobs are directed through the primary server in an SGD array.

5.1.4. Configuring UNIX and Linux Platform Application Servers for Printing

To use PDF printing from a UNIX or Linux platform application server, you must install at least one SGD printer queue on the application server. You do not have to install printer queues for the Universal PDF Printer and Universal PDF Viewer. However, if a UNIX or Linux platform application you are using does not allow you to configure printer arguments, or does not allow you to specify the Universal PDF Printer and Universal PDF Viewer because their names contain spaces, you must install an additional printer queue called tta_pdfprinter and print to that queue.

To use Printer-Direct printing from a UNIX or Linux platform application server, you must install SGD printer queues as follows:

  • Single printer queue. Install an SGD printer queue for the primary SGD server in the array. All print jobs are directed to the primary SGD server, and the primary server sends the print jobs to the client device.

  • Multiple printer queues. Install an SGD printer queue for each SGD server in the array. Each printer queue redirects print jobs to an SGD server, and the SGD server sends the print jobs to the client device.

    Note

    It is best to use multiple printer queues so that print jobs are distributed across the array, and there are no bottlenecks or single points of failure

You configure printer queues with the SGD printer queue installation script. See Section 5.1.4.1, “How to Install an SGD Printer Queue on a UNIX or Linux Platform Application Server”.

The SGD printer queue installation scripts installs replacement lp or lpr scripts. These are used instead of the standard scripts, to ensure that print jobs contain enough information for SGD to be able to identify the user that printed them. See Section 5.1.4.4, “Printing With the SGD lp and lpr Scripts” for details.

5.1.4.1. How to Install an SGD Printer Queue on a UNIX or Linux Platform Application Server

If the application server is also an SGD server, a printer queue is installed automatically when you install SGD.

  1. Copy the /opt/tarantella/bin/scripts/prtinstall.en.sh script from an SGD server to a temporary directory on the application server.

  2. Log in to the application server as superuser (root).

  3. Change to the temporary directory.

  4. Run the script to install the printer queue.

    See Section 5.1.4.2, “The SGD Printer Queue Installation Script” for details of all the command options for the SGD printer queue installation script.

    • If the array consists of a single SGD server, use the following command:

      # sh prtinstall.en.sh

      When prompted, type the full Domain Name System (DNS) name of the SGD server.

    • If the array contains more than one SGD server, create a printer queue for each SGD server in the array. Use the following command:

      # sh prtinstall.en.sh --ttahost DNS-name --appprinter name
      

      The DNS-name is the full DNS name of an SGD server. The name of each printer queue, as specified by the --appprinter argument, can be anything you like but it must be unique.

    If you use the Common UNIX Printing System (CUPS), you might have to use the --cups option with prtinstall.en.sh, to indicate that you are using CUPS. You might also have to reconfigure CUPS. See Section 5.1.4.3, “Configuring Printing for CUPS”.

5.1.4.2. The SGD Printer Queue Installation Script

The SGD printer queue installation script, prtinstall.en.sh, installs an SGD printer queue on a UNIX or Linux platform application server. It also installs the SGD replacement lp or lpr scripts.

The prtinstall.en.sh script is located in the /opt/tarantella/bin/scripts directory on the SGD server.

You must be superuser (root) to run this script.

The syntax for the script is as follows:

sh prtinstall.en.sh [--ttahost SGD_hostname]
                    [--ttaprinter printer_name]
                    [--appprinter printer_name]
                    [--uninstall [printer_name]]
                    [--cups y | n | auto]
                    [--cupsconf filename]
                    [--cupscontrol filename]
                    [--gsbindir gs_bin_dir]
                    [--append]
                    [--help]

The following table describes the available options for the script.

Option

Description

--ttahost SGD_hostname

Fully qualified DNS name of an SGD server

--ttaprinter printer_name

Use this option to specify a name for the printer queue. Use this if the SGD server is also used as an application server. If you do not use this option, the printer is created with the default name of tta_printer.

--appprinter printer_name

Use this option to specify a name for the printer queue on a UNIX or Linux platform application server. If you do not use this option, the printer queue is created with the default name of tta_printer.

--uninstall [printer_name]

Uninstalls an SGD printer queue. If you do not specify a printer queue, you are prompted for one.

--cups y | n | auto

Indicates that you are using CUPS.

If you do not use this option, a default of auto is assumed and this means SGD automatically detects whether CUPS is being used. If CUPS is incorrectly detected, use this option to tell SGD whether CUPS is being used (y) or not (n).

--cupsconf filename

Specifies the path to the CUPS configuration file.

If you do not use this option, the CUPS configuration file is assumed to be /etc/cups/cupsd.conf.

--cupscontrol filename

Specifies the path to the CUPS startup script.

If you do not use this option, the CUPS startup script is assumed to be /etc/init.d/cups.

--gsbindir gs_bin_dir

Use this option to specify the directory where Ghostscript is installed.

Use this option if Ghostscript is not installed in one of the default locations, or to specify the version of Ghostscript to use, if more than one version is installed.

Only use this option if you are running the printer queue installation script on the SGD host. See Section 5.1.5.1, “Checking the Ghostscript Installation on the SGD Host” for details.

--append

Installs an additional printer queue rather than replacing the existing printer queue(s).

--help

Shows the list of prtinstall.en.sh script options.

The following example installs an SGD printer called tta_london on an application server.

# sh prtinstall.en.sh --appprinter tta_london

5.1.4.3. Configuring Printing for CUPS

SGD printing only works with CUPS version 1.1.19 or later. The following configuration changes might be needed to enable printing with CUPS:

  • CUPS LPD compatibility mode must be enabled for any LPD clients.

    If you have any Line Printer Daemon (LPD) clients on your application server, you must enable the CUPS LPD compatibility mode so that CUPS can accept remote print jobs from LPD clients. The CUPS Software Administrators Manual explains how you enable LPD compatibility mode.

  • CUPS raw printing must be enabled.

    On the host where SGD is installed, enable raw printing in CUPS, by editing the /etc/cups/mime.convs and/etc/cups/mime.types files. These files contain comments explaining how to do this. Search for comments containing the word “raw”.

Note

After making changes to your CUPS configuration, you might have to restart the CUPS daemon.

To use CUPS for printing, you must use the /opt/tarantella/bin/lp script.

5.1.4.4. Printing With the SGD lp and lpr Scripts

The SGD printer queue installation script, prtinstall.en.sh, installs the SGD lp or lpr replacement scripts. Users must use these replacement scripts when they print from a UNIX or Linux platform application server. The replacement scripts ensure that print jobs contain enough information for SGD to be able to identify the user that printed them.

The SGD login scripts set the user's PATH to ensure that the replacement scripts take precedence over the system scripts. However, if the application uses a full path name, for example /usr/bin/lp, or modifies PATH itself, you must reconfigure the application to use /opt/tarantella/bin/lp or /opt/tarantella/bin/lpr.

Users print with the replacement scripts as follows:

$ lp -d printer file
$ lpr -P printer file

If the -d or -P argument is omitted, the output goes to the client's default printer. How you specify the printer depends on the client device. See Section 5.1.6, “Configuring Printing to Microsoft Windows Client Devices” and Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices” for details.

5.1.5. Configuring an SGD Server for Printing

Configuring an SGD server for printing involves the following configuration steps:

5.1.5.1. Checking the Ghostscript Installation on the SGD Host

SGD uses Ghostscript to convert print jobs into PDF files. To use PDF printing, Ghostscript must be installed on the SGD host. For best results, install the latest version of Ghostscript. Your Ghostscript distribution must include the ps2pdf program.

With Printer-Direct printing, the tta_print_converter script uses Ghostscript to convert print jobs from PostScript to PCL format. For best results, download and install the additional fonts.

Ghostscript is not included with the SGD software.

When you install SGD, it automatically detects Ghostscript if it is installed in one of the following locations:

  • /usr/local/bin

  • /usr/bin

  • /usr/sfw/bin

  • /opt/sfw/bin

  • /bin

  • /usr/sbin

  • /sbin

  • /usr/lbin

If Ghostscript is installed in a different location, run the SGD printer queue installation script on the SGD host. Use the --gsbindir option of the script to configure the location of Ghostscript. See Section 5.1.4.2, “The SGD Printer Queue Installation Script” for more details.

If more than one version of Ghostscript is installed, run the SGD printer queue installation script with the --gsbindir option, to tell SGD which version to use.

If Ghostscript is not installed on the SGD host, or your Ghostscript distribution does not include the ps2pdf program, install Ghostscript and then run the SGD printer queue installation script.

5.1.5.1.1. Using the gstest Script to Test a Ghostscript Installation

You can use the gstest script to test the Ghostscript installation on an SGD host. This script is run by default when you install SGD.

The gstest script checks for errors in the Ghostscript installation and uses ps2pdf to generate a test PDF file. Script output is reported on-screen, and is also written to the /opt/tarantella/var/log/print.log file.

You run gstest as follows:

# /opt/tarantella/bin/scripts/gstest

Using gstest in this way performs a basic test of the font installation on the SGD host and generates a fonts test file, /opt/tarantella/var/info/sample.pdf. If Ghostscript fonts are installed correctly, the sample.pdf file contains three lines, each rendered in a different font. The fonts used are listed in the /opt/tarantella/var/log/print.log file.

Alternatively, you can specify an input file and output file to use with gstest. For example:

# cd /opt/tarantella/bin/scripts
# gstest /tmp/myPostScriptFile.ps /home/indigojones/myPDFFile.pdf

If you do not specify an output file, gstest creates an output PDF file at /tmp/sgd_sample.pdf.

Note

If you specify your own input file, gstest does not generate the fonts test PDF file, /opt/tarantella/var/info/sample.pdf.

5.1.5.2. Configuring the SGD Host to Accept Remote Print Requests

Print jobs are sent from the application server to an SGD server, and then from the SGD server to the client device. To be able to direct print jobs from an application server to a client device, the SGD host must be configured to accept remote print requests. How you do this varies for each platform. Check your System Administration documentation for information about this.

For example, if you are using lpd on Linux systems, you must add an entry in the /etc/hosts.equiv or /etc/hosts.lpd file, if available, for each application server that might send a print request. After making these changes, remember to restart the lpd daemon.

5.1.5.3. Configuring SGD Print Job Conversion

With Printer-Direct printing, print jobs are sent from an application server to an SGD server. The SGD server then sends the print job to the client device, which sends it to the user's printer. When print jobs arrive at the SGD server, they might need to be converted to a format suitable for the client printer.

Note

Print jobs from Windows RDP sessions are never converted, because they are assumed to be in the correct format.

To decide whether a print job needs to be converted, the SGD server checks a printer type configuration file to see whether the format used by the client printer matches the format used by the application server. If the format matches, the print job is forwarded to the client device printer without any conversion. If the formats do not match, the SGD server converts the print job to the right format using the tta_print_converter script.

To ensure that print jobs are formatted correctly, you might have to edit a printer type configuration file and the tta_print_converter script. This is described in the following sections.

Caution

Only edit these files if you have to use Printer-Direct printing and need to resolve issues with print job formats. In most cases, PDF printing provides a better solution for issues with print job formats.

5.1.5.3.1. Printer Type Configuration Files

SGD uses the following configuration files to determine the printer type:

You can edit these files if you want to support particular printers, or to add new types of printer.

Note

If you add a new printer type, you might also have to edit the tta_print_converter script.

If there is insufficient detail or inaccurate mappings in these files, SGD might convert print jobs unnecessarily, or not at all.

5.1.5.3.2. The tta_print_converter Script

The tta_print_converter script converts print jobs from the format used by the application server to the format required by the client device, as determined by the printer type. By default, the script recognizes PostScript and non-PostScript formats. To convert print jobs from PostScript to PCL, Ghostscript must be installed on the SGD host. See Section 5.1.5.1, “Checking the Ghostscript Installation on the SGD Host” for more information about installing and configuring Ghostscript for SGD printing.

You can edit the tta_print_converter script to recognize and convert between different print job formats, or to add support for a new printer type.

Note

You must log on as superuser (root) to edit the script.

The tta_print_converter script is in the /opt/tarantella/bin/scripts directory. The script includes comments, to help you to customize it.

The shell function GetDataType determines the print job format from the first 128 bytes of the print job. The data is URL-encoded, for example, the % character is encoded as %25.

The client printer type is passed to this script in upper case, for example, POSTSCRIPT or MYNEWTYPE.

If you experience problems printing to a PCL printer, the tta_print_converter script contains some code which has been commented out. You can use this code to see if this solves the problem.

5.1.6. Configuring Printing to Microsoft Windows Client Devices

The configuration required for printing to Microsoft Windows client devices depends on whether you are using PDF printing or Printer-Direct printing, as described in the following sections.

5.1.6.1. PDF Printing

To be able to use PDF printing, the Adobe Reader version 4.0 or later must be installed on the client device.

From a Microsoft Windows application, you print in the normal way, and select either the Universal PDF Printer or the Universal PDF Viewer in the application's Print dialog.

From an application running on a UNIX or Linux platform application server, you print in the normal way, using the SGD replacement lp or lpr scripts. You select a PDF printer as part of the print command, for example:

$ /opt/tarantella/bin/lp -d "Universal PDF Printer" filename
$ /opt/tarantella/bin/lpr -P "Universal PDF Viewer" filename
Note

The filename must be a PostScript file, so the application must be able to output PostScript.

When users print, the PDF file is displayed in the Adobe Reader. If the Universal PDF Printer is selected, the PDF file is printed automatically to the user's default printer. The Adobe Reader runs minimized and does not exit when the print job has finished. If the Universal PDF Viewer is selected, the PDF file is displayed in the Adobe Reader window. The user can then decide whether to print or save the file.

On UNIX, Linux, and Mac OS X platform client devices, the PDF file is displayed either in the default PDF viewer or in the PDF viewer configured in the client profile. The user can then decide whether to print or save the PDF file. There is no difference between the Universal PDF Printer and the Universal PDF Viewer, as the print job is always displayed in a PDF viewer.

5.1.6.2. Printer-Direct Printing

This section describe the configuration that might be needed when using Printer-Direct printing to print to Microsoft Windows client devices and includes the following topics:

5.1.6.2.1. Printer Driver Mapping

When printing from a Microsoft Windows application, the large number and variety of client printers available can cause problems. The majority of the problems are caused by not having the correct printer drivers installed on the application server. One solution is to use PDF printing. Another solution, for Windows client devices only, is to use printer driver mapping.

Printer driver mapping enables you to map one printer driver name to another. You do this by editing the [Previous Names] section of the /opt/tarantella/etc/data/default.printerinfo.txt file.

The following is an example of an entry in a default.printerinfo.txt file:

[Previous Names]
"HP LaserJet 5"="my HP driver", "my other HP driver"

This means that if users have client printers that use either the "my HP driver" or "my other HP driver" printer driver, SGD uses the "HP LaserJet 5" printer driver when creating the printer.

You can also use wild-card characters, such as * and ?, on the right hand side of the = sign. Use * to mean any string of characters, including an empty string and ? to mean any single character. This is useful, for example, to create generic printer mappings where you have a wide variety of client devices.

For example, if the file contains the following entry:

[Previous Names]
"HP LaserJet 5"="hp*laserjet 5*"

All printer driver names like "HP LaserJet 5", "HP LaserJet 5M", and "HP Color LaserJet 5" are mapped to the printer driver "HP LaserJet 5".

The default.printerinfo.txt file contains more detailed instructions on how to create the mappings.

5.1.6.2.2. The Printer Types Configuration File

For Microsoft Windows client devices, SGD uses the /opt/tarantella/etc/data/printertypes.txt file to determine whether to convert a print job from one format to another before sending it to the client device. The printertypes.txt file maps printer drivers, for example, pscript.dll, to printer types, for example PostScript.

Note

Print jobs from Windows RDP sessions are never converted, because they are assumed to be in the correct format.

The printertypes.txt file includes comments to help you to customize it. By default, the file includes mappings for PostScript, PCL, and text-only printers. You must log on as superuser (root) to edit this file.

Note

The printertypes.txt file used for Windows clients also contains entries for UNIX platform and Apple Macintosh clients. This is used only as a fallback. For UNIX or Linux platforms, it maps UNIX types to printer types. For Apple Macintosh, it maps printer names to printer types.

To find out the name of the printer driver used by a client device, print a test page and check the Driver Name field.

To add support for a new printer type, add lines following the same pattern. For example:

MyNewType=mydriver.drv

For example, a Windows client device, cairo, runs Windows and its default printer is PCL. The printer driver used is unidrv.dll. The [Windows*] section in printertypes.txt has the following format:

[Windows*]
PostScript=pscript5.dll;pscript.dll
PCL=rasdd.dll
PostScript=*

As there is no specific match for unidrv.dll, the final entry applies: PostScript. This means that when the user prints, print jobs are incorrectly converted to PostScript before being sent to cairo.

To fix this, edit printertypes.txt as root and add a specific match for unidrv.dll as follows:

PCL=rasdd.dll;unidrv.dll

Following this change, SGD correctly identifies the printer configured on cairo, and print jobs are converted to PCL for that client device.

5.1.6.2.3. Printing From a UNIX or Linux Platform Application Server

When printing from a UNIX or Linux platform application server to a Microsoft Windows client device, users can specify the printer they print to by using any of the following:

  • The Universal Naming Convention (UNC) name of a network printer accessible to the client, for example:

    $ lp -d '\\\\PRTSERVER\\HPLJ5' filename
    
  • A “friendly” name, for example:

    $ lpr -P label-printer filename
    
  • A port on the client, for example:

    $ lpr -P LPT1: filename
    

To use a UNC name, you must enclose the printer name in quotes and escape every backslash with an extra backslash, as shown in the previous example. As different shells process backslashes differently, you might need to experiment with the number of backslashes. You can also use underscores instead of backslashes, for example:

$ lp -d __PRTSERVER_HPLJ5 filename
Note

Using underscores only works if the first two characters of the printer name are underscores.

You can avoid problems with UNC names by using a “friendly” name. You configure “friendly” names in the /opt/tarantella/etc/data/printernamemap.txt file. The entries in this file map “friendly” names to UNC names, for example:

"label-printer"="\\PRTSERVER\HPLJ5"
Note

You do not have to escape any backslashes.

5.1.7. Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices

The configuration required for printing to UNIX, Linux, and Mac OS X platform client devices depends on whether you are using PDF printing or Printer-Direct printing, as described in the following sections.

5.1.7.1. PDF Printing

To be able to use PDF printing, a PDF viewer must be installed on the client device. SGD supports the following PDF viewers by default.

Client Platform

Default PDF Viewer

Oracle Solaris on SPARC platforms

GNOME PDF Viewer (gpdf)

Acrobat Reader (acroread)

Oracle Solaris on x86 platforms

GNOME PDF Viewer (gpdf)

Linux

GNOME PDF Viewer (gpdf)

Evince Document Viewer (evince)

X PDF Reader (xpdf)

Mac OS X

Preview App (/Applications/Preview.app)

Note

The Adobe Reader PDF viewer must support the -openInNewWindow command option. The Preview App PDF viewer must support the open -a command option.

To be able to use a default PDF viewer, the application must be on the user's PATH.

If an alternative PDF viewer is preferred, the command for the alternative viewer application can be configured in the user's client profile. In the profile you enter either the command or the full path to the command, depending on whether the application is on the user's PATH. See Section 6.2.4, “Client Profile Settings” for details.

From a Microsoft Windows application, you print in the normal way, and select either the Universal PDF Printer or the Universal PDF Viewer in the application's Print dialog.

From an application running on a UNIX or Linux platform application server, you print in the normal way, using the SGD replacement lp or lpr scripts. You select a PDF printer as part of the print command, for example:

$ /opt/tarantella/bin/lp -d "Universal PDF Printer" filename
$ /opt/tarantella/bin/lpr -P "Universal PDF Viewer" filename
Note

The filename must be a PostScript file, so the application must be able to output PostScript.

The PDF file is displayed either in the default PDF viewer or in the PDF viewer configured in the client profile. The user can then decide whether to print or save the PDF file. There is no difference between the Universal PDF Printer and the Universal PDF Viewer, as the print job is always displayed in a PDF viewer.

5.1.7.2. Printer-Direct Printing

To use Printer-Direct printing to print to printers attached to UNIX, Linux, or Mac OS X platform client devices, the client printers must be defined in one of the following printer configuration files:

  • Global printer configuration file /opt/tarantella/etc/data/default.printerinfo.txt.

    This file set the defaults for all users printing through that SGD server. As this file is not replicated across the array, you have to manually copy it to the other SGD servers.

  • User-specific printer configuration file$HOME/.tarantella/printerinfo.txt.

    The user-specific printer configuration file is optional and has to be manually created on client devices. Users can create their own file or you can use the global configuration file as a template and distribute it to users. This file contains the settings for an individual user regardless of the SGD server they print through. The settings in this file take precedence over the settings in the global configuration file.

The format of the global and user-specific printer configuration file is the same:

[UNIX]
"printer-name"="windows-driver" printer-type
"printer-name"="windows-driver" printer-type
...

printer-name is the name of the printer as it is known to the lp or lpr system on the client. The printer name must be enclosed in straight quotation marks (") and be followed by an Equal (=) sign. This is the name that users can specify when printing from a UNIX or Linux platform application server. It is also the name that displays in the Print dialog when users print from a Microsoft Windows application server.

windows-driver is the name of the printer driver to use when printing from a Microsoft Windows application server. The printer driver name must be enclosed in double quotes. The name of the printer driver must match the name of the printer driver installed on the Windows application server exactly. Pay particular attention to the use of capitals and spaces. The default.printerinfo.txt file contains all the common printer driver names ordered by manufacturer. To avoid errors, copy and paste the driver name from this file.

printer-type is the format to be used for the print job. The values can be PostScript, PCL or Text. This information is optional, but if it is missing, PostScript is used by default. This information is used to determine whether SGD converts the print job from the format used by the application server to the format needed by the client printer. See also Section 5.1.5.3, “Configuring SGD Print Job Conversion”.

The first printer listed in the [UNIX] section is the client's default printer.

When SGD is first installed, the default.printerinfo.txt file contains the following entry:

[UNIX]
"_Default"="HP Color LaserJet 2800 Series PS" PostScript

With this configuration, when users print from a Windows application server, they see a printer called _Default. This printer prints to the default printer on the client using a basic PostScript printer driver, “HP Color LaserJet 2800 Series PS”.

Note

This means that a printer is available in the Windows application, even if there is no printer connected to the client device.

For example, if an SGD user's $HOME/.tarantella/printerinfo.txt file contains the following entries:

[UNIX]
"drafts"="HP Diskette 970Cxi" PCL
"salespersons"="HP Lacerate 5/5M" PostScript

When the user prints from a Microsoft Windows application server to a UNIX platform client device, the following printers are available:

  • drafts

  • salespersons

The user's default printer is drafts, which in this example has been defined as a PCL printer.

5.1.8. Managing Printing

This section describes the print job management features of SGD and includes the following topics:

5.1.8.1. The tarantella print Command

SGD Administrators control printing services with the tarantella print command. This command enables you to do the following:

  • List spooled print jobs and identify the SGD users they belong to. You can use this to check that print jobs from the application server printing system have reached the SGD print queue.

  • Remove print jobs from the SGD print queue.

  • Pause and restart SGD printing services.

  • Move print jobs from one SGD server to another.

The syntax for the tarantella print command is as follows:

tarantella print start | stop | status | pause | resume | list | cancel | move

The following table shows the available subcommands for tarantella print.

Subcommand

Description

cancel

Cancels print jobs

list

Lists print jobs

move

Moves queued print jobs from one SGD server to another

pause

Pauses printing temporarily

resume

Resumes printing

start

Starts printing services for the array

status

Displays information about printing services

stop

Stops printing services

5.1.8.2. Setting a Time Limit for Print Jobs

SGD Administrators can set a time limit on how long a print job can remain on an SGD server before it is deleted. This is useful if you have to manage a high volume of printing.

To specify the number of hours that print jobs remain on the server, use the following command:

$ tarantella config edit \
--tarantella-config-array-printjoblifetime hours

To return SGD to its default behavior, so that print jobs remain on the server indefinitely, use the following command:

$ tarantella config edit \
--tarantella-config-array-printjoblifetime 0

5.1.8.3. User Management of Print Jobs

Users can manage their own print jobs from the Printing area on the webtop, as shown in Figure 5.1, “Printing Area on the SGD Webtop”.

Figure 5.1. Printing Area on the SGD Webtop

Screenshot Showing the Printing Area on the SGD Webtop

The Printing area shows the number of jobs currently in the print queue and the controls for managing print jobs.

When documents are printing, the webtop tells a user how many print jobs they have in the queue. Users can click Cancel All to delete all pending print jobs.

Users can also click Pause to temporarily stop printing. When printing is paused, any print jobs that are pending are held in a queue until the user either cancels them or resumes printing. Click Resume to start printing again. The printer icon changes to show you when printing is paused.

To manage print jobs individually, click List all jobs. The webtop displays a list of all the print jobs the user has in the queue, along with information about the job, for example the number of copies and the selected printer.

If you pause printing, click the Resume button to print just that one print job.

To cancel a print job, click the Cancel button.

When printing from a Microsoft Windows application server, or a UNIX or Linux platform application server, users can choose which printer they print to. If the user does not select a printer, the output goes to their default printer. For all other application servers, the output always goes to the client device's default printer.

Users can see which printer is their default printer by pointing with the mouse at the printer icon on their webtop. A popup displays the name of the default printer.

If a user wants to change their default printer, they must log out of SGD, change the default printer and then log in to again.

5.1.9. Users Cannot Print From Applications Displayed Through SGD

Use the following checklists to diagnose and fix the problem:

If this does not resolve the problem, follow the steps in Section 5.1.9.4, “Tracing a Print Job”.

5.1.9.1. Client Devices Checklist

Use the following client device troubleshooting steps to diagnose printing problems in SGD.

Questions

  • 5.1.9.1.1: Does SGD Support Printing for the Client Device or Printer Type?

  • 5.1.9.1.2: Is Printing Paused on the Client Device?

  • 5.1.9.1.3: Is the Printer Configured Correctly?

  • 5.1.9.1.4: For PDF Printing, is the PDF Viewer Installed on the Client?

  • 5.1.9.1.5: For PDF Printing From a UNIX or Linux Platform Application Server, is the Print Job in the Right Format?

  • 5.1.9.1.6: Does the User Have the Necessary Registry Permissions?

Questions and Answers

5.1.9.1.1: Does SGD Support Printing for the Client Device or Printer Type?

Check the Printing Area on the webtop. Does the printer icon contain a red cross and is the message “No Client Printer Available” displayed? If so, this means that SGD does not support printing for this client device or printer type, or that there was an error creating client printers.

5.1.9.1.2: Is Printing Paused on the Client Device?

Make sure that the user has not paused printing. Check the Printer Paused icon is not displayed.

Use the tarantella webtopsession list command to see whether the user has paused printing.

5.1.9.1.3: Is the Printer Configured Correctly?

Make sure that the printer is correctly configured, for example by printing a web page to the printer from a web browser on the client device. Depending on the application server, some print jobs can only go to the client device's default printer.

If printing to a UNIX, Linux, or Mac OS X platform client device, check that you have configured printing for these client types. See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”.

5.1.9.1.4: For PDF Printing, is the PDF Viewer Installed on the Client?

To be able to use PDF printing in SGD, a PDF viewer must be installed on the client device.

Check that the supported viewer, or the user's preferred viewer, is installed on the client and that the application is executable.

On UNIX, Linux, or Mac OS X system client devices, check that the user has read and write access to the /tmp directory.

If the PDF viewer is Adobe Reader (acroread), check that the viewer supports the -openInNewWindow command option. If the PDF viewer is Preview app (/Applications/preview.app), check that the viewer supports the open -a command option.

If a PDF viewer is not installed or accessible, the SGD PDF printers are available to the user.

5.1.9.1.5: For PDF Printing From a UNIX or Linux Platform Application Server, is the Print Job in the Right Format?

If the user's PDF viewer starts, but they receive a file format error, check that the format of the file being printed on a UNIX or Linux platform application server is PostScript.

5.1.9.1.6: Does the User Have the Necessary Registry Permissions?

On Microsoft Windows client devices, users must have write access to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed registry key and read access to the rest of the registry.

This access is required by several of the Windows application programming interfaces (APIs) for printing.

5.1.9.2. Application Server Checklist

Use the following application server troubleshooting steps to diagnose printing problems in SGD.

Questions

  • 5.1.9.2.1: Is Printing Enabled on the Application Server?

Questions and Answers

5.1.9.2.1: Is Printing Enabled on the Application Server?

Before users can print, you might need to enable printing services on your application server.

On Microsoft Windows application servers, printer mapping must be enabled. Printer mapping is configurable globally, or as a group policy. By default, printer mapping is enabled.

On UNIX and Linux platform application servers, printing services must be enabled.

Questions

  • 5.1.9.2.1: Is a Printer Configured on the Application Server?

  • 5.1.9.2.2: Is the Printer Created in the Windows Application Session?

  • 5.1.9.2.3: Is the Application Printing to the Correct Printer?

  • 5.1.9.2.4: Are Accounts Shared on the Application Server?

  • 5.1.9.2.5: Is the Windows Name of the Server the Same as the DNS Name?

  • 5.1.9.2.6: If You Are Using PDF Printing, is the Same PostScript Printer Driver Installed on Every Microsoft Windows Application Server?

Questions and Answers

5.1.9.2.1: Is a Printer Configured on the Application Server?

Before users can print, you might need to configure a SGD printer on your application server. See the following:

5.1.9.2.2: Is the Printer Created in the Windows Application Session?

If the user is trying to print from a Microsoft Windows application server, accessed using Windows Remote Desktop Services, then the user's printers are configured automatically. See Section 5.1.3.1, “Configuring Printing for Microsoft RDP 5.0 or Later”. If not, check the System event log on the application server for the following errors:

  • Event ID: 1111 Description: Driver drivername required for printer printertype is unknown. Contact the administrator to install the driver before you log in again.

  • Event ID: 1105 Description: Printer security information for the printername / clientcomputername /Session number could not be set

  • Event ID: 1106 Description: The printer could not be installed.

These errors indicate that the printer driver for the client printer might not be supported by the application server. Either install the printer driver on the application server, or see Section 5.1.6.2.1, “Printer Driver Mapping” for details of how to support other printer drivers, including using wildcards to support a wide range of printer driver names.

It is also worth checking that the name of the printer driver in /opt/tarantella/etc/data/default.printerinfo.txt, or the user's $HOME/.tarantella/printerinfo.txt, matches the name of the driver on the application server.

If this does not resolve the problem, see Microsoft Knowledge Base article 239088 for more details.

5.1.9.2.3: Is the Application Printing to the Correct Printer?

The application must print to the printer queue you have configured. On UNIX or Linux platform application servers, the prtinstall.en.sh script creates a printer queue named tta_printer by default.

On UNIX or Linux platform application servers, the application must print using the replacement lp or lpr scripts installed by prtinstall.en.sh. The SGD login scripts set PATH to ensure that the replacement scripts take precedence over the system scripts. If the application uses a full path name, for example /usr/bin/lp, or modifies PATH itself, reconfigure the application to use /opt/tarantella/bin/lp or /opt/tarantella/bin/lpr.

5.1.9.2.4: Are Accounts Shared on the Application Server?

If more than one user is simultaneously logged in to the same application server with the same user name, SGD might be unable to distinguish which user owns the print jobs. SGD discards the print jobs, logging that it has done so. This occurs with UNIX or Linux system application servers that do not have an SGD printer queue.

To fix this problem, run the prtinstall.en.sh script to configure a printer. See Section 5.1.4.2, “The SGD Printer Queue Installation Script”.

Use the tarantella print command to check that print jobs from the application server printing system are reaching the SGD print queue.

5.1.9.2.5: Is the Windows Name of the Server the Same as the DNS Name?

If you have a Microsoft Windows NT server with a DNS name of naples.example.com and a NetBIOS name of VESUVIUS, print jobs from this server fail, because they contain the host identifier VESUVIUS instead of naples.

You can avoid this problem by editing the file hostnamemap.txt in the /opt/tarantella/etc/data directory. This file enables you to map host names to DNS names. The file contains instructions on how to create the mappings.

5.1.9.2.6: If You Are Using PDF Printing, is the Same PostScript Printer Driver Installed on Every Microsoft Windows Application Server?

To be able to use PDF printing, you must install the same PostScript printer driver on every Microsoft Windows application server.

In the Administration Console, check that the name of the driver matches the name configured in the Postscript Printer Driver field on the Global Settings → Printing tab, or the Printing tab for the user profile or parent object. The System event log on the application server shows an error if the names do not match.

5.1.9.3. SGD Server Checklist

Use the following SGD server troubleshooting steps to diagnose printing problems in SGD.

Questions

  • 5.1.9.3.1: Is Printing Paused or Disabled Across the Array?

  • 5.1.9.3.2: For Printing on Microsoft Windows Client Devices, Are Client Printers Disabled?

  • 5.1.9.3.3: Has the Array Configuration Changed?

  • 5.1.9.3.4: For PDF Printing, is Ghostscript Available on the SGD Host?

Questions and Answers

5.1.9.3.1: Is Printing Paused or Disabled Across the Array?

Use the tarantella print status command to check whether printing is paused or disabled for the array.

If necessary, enable printing, using tarantella print start or tarantella print resume.

5.1.9.3.2: For Printing on Microsoft Windows Client Devices, Are Client Printers Disabled?

In the Administration Console, check the Global Settings → Printing tab, or the Printing tab for the user profile or parent object. See whether users can access all their client printers, just their default client printer, or no client printers.

For PDF printing, check whether the SGD PDF printers are enabled.

5.1.9.3.3: Has the Array Configuration Changed?

Printing is not reconfigured if you do any of the following:

  • Create an array

  • Add a new secondary server to the array

  • Change the primary server in the array

If the array has changed you might have to reconfigure printing, so that print jobs are sent to the correct printer.

5.1.9.3.4: For PDF Printing, is Ghostscript Available on the SGD Host?

PDF printing in SGD uses Ghostscript to convert print jobs into PDF files. SGD also uses Ghostscript to convert print jobs from PostScript to PCL.

Try upgrading to the latest version of Ghostscript. After upgrading, ensure that the symbolic link /opt/tarantella/var/info/gsbindir points to the directory where the new Ghostscript binaries are installed.

If the /opt/tarantella/var/log/print.log file contains a message such as "Can't find ps2pdf" or "Consider obtaining Ghostscript from http://www.ghostscript.com", then either Ghostscript is not installed or it is installed in a non-standard location.

See Section 5.1.5.1, “Checking the Ghostscript Installation on the SGD Host” for details of how fix Ghostscript installation problems.

5.1.9.4. Tracing a Print Job

If the checklists above do not solve your SGD printing problem, try the following troubleshooting steps. These steps enable you to track the progress of a print job from the application server to the SGD server to the client device.

Questions

  • 5.1.9.4.1: Step 1: Can You Print From the SGD Server?

  • 5.1.9.4.2: Step 2: Is the SGD Printer Queue Installed on the SGD Server?

  • 5.1.9.4.3: Step 3: Is the Print Job Leaving the UNIX or Linux Platform Application Server?

  • 5.1.9.4.4: Step 4: Is the Print Job Present in the UNIX or Linux System Spool Directory?

  • 5.1.9.4.5: Step 5: Is the Print Job Leaving the Windows Application Server?

  • 5.1.9.4.6: Step 6: Is the Print Job Reaching the SGD Server?

  • 5.1.9.4.7: Step 7: Have You Examined the Print Log Files?

Questions and Answers

5.1.9.4.1: Step 1: Can You Print From the SGD Server?

Configure an X or character application to run on the SGD server. Display a terminal window, for example xterm, and start the application from your SGD webtop.

Try printing a test page, by running the /opt/tarantella/bin/scripts/printtestpage.en.sh script.

If the page does not print, run /opt/tarantella/bin/scripts/printtestpage.en.sh --direct. This bypasses the UNIX or Linux system spooler.

Check the following:

  • Did the first test page print?

    The problem is related to the movement of print jobs from the application server to the SGD server.

    • For UNIX or Linux platform application servers, go to TO DO: LINK TO STEP 3 .

    • For Windows Remote Desktop Services, go to TO DO: Link to Step 5 .

  • Did the second test page print?

    The problem is related to the UNIX or Linux system printing system on the SGD host.

    Investigate and fix any problems, using your UNIX or Linux system documentation for help. Then try printing again.

  • Did neither of the test pages print?

    The problem is related to the SGD server.

    Go to TO DO: Link to Step 2 .

5.1.9.4.2: Step 2: Is the SGD Printer Queue Installed on the SGD Server?

In the list of printers on the SGD host, check for an entry for tta_printer.

Consult your UNIX or Linux system documentation to find out how to display the list of printers. On some systems, you can use lpstat -t. If your system has a file /etc/printcap, this contains a list of printers in plain text format.

Check the following:

  • Is the tta_printer printer present on the SGD host?

    The problem is related to the movement of print jobs from the SGD server to the client device. Go to TO DO: Link to Step 7 .

  • Is the tta_printer printer missing from the SGD host?

    Run the prtinstall.en.sh script on the SGD server. Then try printing again.

    See also Section 5.1.4.2, “The SGD Printer Queue Installation Script”.

5.1.9.4.3: Step 3: Is the Print Job Leaving the UNIX or Linux Platform Application Server?

Using an application object configured to display a terminal window on the UNIX or Linux system application server, try printing a small text file to the SGD printer. For example, type the command: lp -d tta_printer /etc/hosts.

Check the following:

  • Does the command return an error message?

    Check that the UNIX or Linux platform application server is configured to print through SGD. You might need to run the prtinstall.en.sh script. See Section 5.1.4.2, “The SGD Printer Queue Installation Script” for more details.

  • Does the command return a print job ID?

    This suggests that SGD printing is correctly configured, but the problem might lie in the UNIX or Linux print system. Go to TO DO: Link to Step 4 .

5.1.9.4.4: Step 4: Is the Print Job Present in the UNIX or Linux System Spool Directory?

The print spool directory varies between different UNIX or Linux systems. Consult your UNIX or Linux system documentation for assistance.

Check the following:

  • Is the print job present in the spool directory?

    There might be a network problem between the application server and SGD server. Go to TO DO: Link to Step 6 .

  • Is the print job missing from the spool directory?

    Check your UNIX or Linux system LPD printing configuration. For example, ensure that there are suitable entries in /etc/hosts.equiv or /etc/hosts.lpd, and that there are no .deny files, such as /etc/hosts.equiv.deny.

    Check that the lpd daemon is running and listening. For example, use the following commands:

    # ps -ef | grep lpd
    # netstat -a | grep printer

    Try printing again.

5.1.9.4.5: Step 5: Is the Print Job Leaving the Windows Application Server?

Check the print queue on the application server. Consult your system documentation if you need help on how to do this.

Check the following:

  • Is the print job leaving the application server?

    There might be a network problem between the application server and SGD server. Go to TO DO: Link to Step 6 .

  • Is the print job leaving the application server?

    Check the configuration of the SGD printer, as follows:

    • Check that you can ping and telnet to the SGD server from the application server.

    • Look for errors in the Event Log.

    • From a command prompt, use the lpr -s server -p tta_printer filename command to print. If this works, the printer driver on the application server might not be installed or configured correctly.

5.1.9.4.6: Step 6: Is the Print Job Reaching the SGD Server?

Check the SGD print spool directories on the SGD server: /opt/tarantella/var/spool and /opt/tarantella/var/print/queue.

Check the following:

  • Is the print job present on the SGD server?

    Check that you are using fully qualified DNS names in the application object, and that name resolution is working correctly.

    Examine the printing log files for more information. Go to TO DO: Link to Step 7 .

  • Is the print job missing from the SGD server?

    Check the configuration of the SGD server, as follows:

    • Check your UNIX or Linux system LPD printing configuration.

      For example, ensure that there are suitable entries in /etc/hosts.equiv or /etc/hosts.lpd, and that there are no .deny files, such as /etc/hosts.equiv.deny.

      Check that the lpd daemon is running and listening. For example, use the following commands:

      # ps -ef | grep lpd
      # netstat -a | grep printer
    • Check that you can ping and telnet to the SGD server from the application server.

    • If you are using Windows Remote Desktop Services, display a command prompt and use the lpr -s server -p tta_printer filename command to print. If this works, this suggests the printer driver on the application server is not installed or configured correctly.

5.1.9.4.7: Step 7: Have You Examined the Print Log Files?

You can use the tarantella query command to examine the logs across the array. Log files are stored in /opt/tarantella/var/log on each SGD server in the array.

If the print log files are empty, edit the Log Filter, to log printing messages. In the Administration Console, go to the Global Settings → Monitoring tab, and add the following log filters:

server/printing/*:print%%PID%%.log
server/printing/*:print%%PID%%.jsl

If the log contains messages indicating problems with user name mappings, this suggests you are using shared accounts on the application server. See TO DO: Link to appserver shared accounts .

5.1.10. Troubleshooting Other Printing Problems

This section describes some typical problems when printing through SGD and includes the following topics.

5.1.10.1. Troubleshooting Printer Preferences and Settings

When printing from a Windows application, users can set preferences for the printers they use. The following are common problems with printer preferences.

5.1.10.1.1. Current Client Printer Preferences Are Ignored

The first time a client printer is defined for a user, the printer preferences, such as the paper size and orientation, are the application server's defaults for the printer driver and not the client printer's current preferences.

Users can change the printer preferences on the application server, and these modified preferences are used when they next connect using a client device with the same printer.

5.1.10.1.2. Changes to Printer Preferences Are Not Remembered

When a user changes their printer preferences, for example by changing the default paper size, sometimes the change is not remembered when they next run a Windows application.

There is a delay between changing the preferences and the new preferences being sent to the client. When changing printer preferences, it is advisable to wait a few minutes before logging out of the Windows application.

5.1.10.1.3. Printer Preferences Are Corrupted

If large numbers of client printers are present, printer preferences can sometimes become corrupted.

Use the Printer Preference Caching (--noprintprefs) attribute to disable the storing of printer preferences for a Windows application, as follows:

$ tarantella object edit --name appname --noprintprefs 1

where appname is the name of the Windows application.

5.1.10.1.4. Printer Preferences Are Lost When a User Changes Printers

Printer preferences are linked directly to the driver name. So, if a user changes the printer they use and the new printer uses a different driver name, they have to set the printer preferences again.

5.1.10.1.5. Local Printer Settings Are Not Set in the Remote Windows Application Session

The printer settings of a local printer are not set on the printer in the remote Windows application session when you use SGD. However, they are set when you use the Microsoft Remote Desktop Connection client.

SGD does not support this capability.

5.1.10.1.6. Printer Settings Are Ignored When Using PDF Printing

If you are using PDF printing on a Microsoft Windows client device, some printer settings might be ignored by the Adobe Reader.

This might be because the printer driver used for PDF printing has settings that are not available on the client printer.

Some settings, such as page orientation, have to be set in the Adobe Reader print dialog, as well as on the printer in the Windows application session. Once you have set up the Reader, the settings are remembered.

5.1.10.2. Print Jobs Can Be Queued When SGD Printing is Disabled

After disabling the SGD print system, by running tarantella print stop, it is still possible to spool print jobs on application servers. These jobs remained queued until SGD printing is restarted.

To prevent print jobs from being submitted, disable the SGD print queue manually on the application servers.

5.1.10.3. Fonts Do Not Print Correctly With PDF Printing

When using PDF printing, users might find that the fonts on the printed output are not what they expected.

As PDF printing relies on a combination of Windows printer drivers, when printing from Windows applications, Ghostscript and a PDF viewer to deliver its output, you might have to experiment with the font settings for each of these components to see if this produces a better result.

5.1.10.3.1. TrueType Fonts and Windows Applications

When printing from a Windows application and the document contains TrueType fonts, users might find that the printer is using its own fonts, called device fonts, instead of the TrueType fonts. This can result in some characters being printed as “empty boxes” ([]).

The solution to this problem is to force the printer to download the TrueType fonts for printing.

Display the Print dialog in the Windows application and select Properties → Advanced. In the Graphic section, change the TrueType Font option to Download as Softfont.

5.1.10.4. Changing Printer Names in Windows Application Sessions

The names of printers created in a Windows Remote Desktop Services session depend on the client device platform.

For Unix, Linux, and Mac OS X platform client devices, the name comes from the printer configuration file used for the client device. See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices” for more details.

For Windows client devices, the name comes from the printer driver.

If you are using PDF printing, you can amend the names of the PDF printers. See Section 5.1.10.5, “Changing the Names of the SGD PDF Printers”.

5.1.10.5. Changing the Names of the SGD PDF Printers

The names of SGD PDF printers are configurable. You can amend these names as follows.

To change the PDF printer names for all users, use the following command:

$ tarantella config edit \
--printing-pdfprinter name --printing-pdfviewer name

To change the PDF printer names for an organization, organizational unit, or user profile object, the object must also be configured to override the parent object's printing settings. Use the following command:

$ tarantella object edit --name object \
--userprintingconfig true --pdfprinter name --pdfviewer name

5.1.10.6. Users See a Printer Called _Default in a Windows Application Session?

Users who access Windows applications from UNIX, Linux, or Mac OS X platform client devices, might see a printer called _Default in their Windows application session. This can be confusing to users if their client printer has a different name or they have no client printer.

This is caused by the default setting in the printerinfo.txt file, which is used to associate the printer driver name with a print job when printing from a Windows application.

To correct the printer name, edit the printerinfo.txt file.

To remove the _Default printer name, delete the _Default entry from the printerinfo.txt file.

See Section 5.1.7, “Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices”, for more details about the printerinfo.txt file.