Difference: ClientSidePrinting (1 vs. 2)

Revision 22016-02-19 - JeanNeron

Line: 1 to 1
 
META TOPICPARENT name="SpotlightTechTips"

Tech Tip - Client Side Printing

by Gary Rogers, APPX Director of Training and Consulting

Changed:
<
<
With the advent of the APPX Desktop Client, a broad range of features were introduced that opened up integration between APPX and the desktop. One of the most useful features is client-side printing. In this issue’s Tech Tip we will explore some of the options and the workings of using client side printing.
>
>
With the advent of the APPX Desktop Client, a broad range of features were introduced that opened up integration between APPX and the desktop. One of the most useful features is client-side printing. In this issue’s Tech Tip we will explore some of the options and the workings of using client side printing.
  In simple terms, client-side printing allows the user to print to a printer defined on the desktop rather than the server. That frees the user from the need to have a connection to the server for printing needs. It opens up printing to any printer at any remote location whether the server where APPX is running can see it or not. Prior to client-side printing all reports were printed from the server. Employees and customers can now access and print reports from home, from the road, or even while at the airport.
Changed:
<
<
It sounds simple enough, and it is. There are only a few of things that need to be done to implement client side printing: 1) Install the Appx Desktop Client. 2) Set one or more printer definitions in APPX for client-side printing. 3) Define one of those printers in the print disposition when creating the report. Do those things and it should just work. Famous last words, right?

Installing the client is easy. On this website ( www.appx.com), follow the menus to Downloads, then Desktop Products. Select the client for your desktop (Windows, Mac, or Linux), save it to disk and install. You can take the defaults for a quick installation. Make sure the listener daemon (appxd, WinAppxD, or AppxDSvc) is set up on your server and connect to Appx using the client.

>
>
It sounds simple enough, and it is. There are only a few of things that need to be done to implement client side printing:
  1. Install the Appx Desktop or HTML Client (with the local connector).
  2. Set one or more printer definitions in APPX for client-side printing.
  3. Define one of those printers in the print disposition when creating the report.
Installing the APPX Desktop client is easy. On this website ( www.appx.com), follow the menus to Downloads, then Desktop Products. Select the client for your desktop (Windows, Mac, or Linux), save it to disk and install. You can take the defaults for a quick installation. The HTML client does not require any installation, simply go to the URL where the HTML client has been installed (consult your Sys Admin or developer if you aren't sure). You will need the local connector, if web page prompts you to install the local connector, then follow the instructions to install it. If the web page does not prompt you and the 'Local' button in the lower right corner of the web page is red, then you cannot print to a local print with the HTML client. Again, consult a local expert on whether this feature can be enabled or not.
  When setting up a printer for client-side printing, it is as simple as going to the second screen on the printer setup in System Administration and setting the Print to Client flag to Yes (a check mark in the client). You can set up as many client printers as you would like. There are a couple of caveats to this, depending on the release of APPX you are running. Those will be discussed later in this article.

Now you are ready to print to the desktop. All you need to do is place the printer name you set up for client printing in the Printer ID field on the disposition screen or set the name into --- PRINT PRINTER ID work field. APPX does not do anything different to create the report for client side printing. The report and configuration files are created as always and placed in the usual server directory. The report can still be displayed to the screen before printing, and the output can be text or PDF. When APPX goes to actually print the hardcopy things are done a bit differently.

Changed:
<
<
Normally APPX will pass the name of the print and configuration files to the server’s print manager by executing the appx_print script (winprint.exe on Windows), unless the output is PDF. When the printer is set to print to the client, APPX bypasses that process and instead calls an internal routine equivalent to --- SEND FILE TO CLIENT to put the print and configuration files on the user’s desktop. The internal routine for --- LOAD URL ON CLIENT is then executed to pass a command line to invoke the nativeWindows.dll (formerly known as winprintdll.dll). The .dll then formats the info and passes it to the Windows print manager.
>
>
Normally APPX will pass the name of the print and configuration files to the server’s print manager by executing the appx_print script (winprint.exe on Windows), unless the output is PDF. When the printer is set to print to the client, APPX bypasses that process and instead calls an internal routine equivalent to --- .CLIENT DOWNLOAD FILE to put the print and configuration files on the user’s desktop. The internal routine for --- .CLIENT LOAD URL is then executed to pass a command line to invoke the nativeWindows.dll (formerly known as winprintdll.dll). The .dll then formats the info and passes it to the Windows print manager.
  As simple as that sounds there are a few other things that are helpful to know about, as well as those caveats mentioned earlier. First, the printer name. When you set up the printer in APPX you can enter an OS printer name in the System ID field. That system ID is then passed to the .dll and on to the print manager to direct the output to the proper printer. When client side printing was introduced, the System ID field was made optional. When left blank, APPX does not pass a printer name and the print manager will send the output to the default desktop printer. That is the most common setup, as this allows pretty much any user to use the default printer ID and have the report print. Prior to APPX 4.2.8, the System ID field was an Alternate Unique key and only one printer could be defined without an ID. From 4.2.8 forward the System ID is now a standard alternate key and you can define as many printers as you would like with no System ID.

If you enter a printer name in the System ID field, APPX will place the name in the configuration file for the .dll to pass to the print manager to use. Here is one of those caveats. The printer ID must be defined as a desktop printer or the file will not print. Also, there was a bug in some of the 4.1.x versions of the winprintdll.dll that would crash the client if the printer could not be found. The fix for that bug is to install an older winprintdll.dll or upgrade to the 4.2.x client. Related to that, if you use a System ID for a client printer, then that printer name must be set up on any and all desktops that will use that printer in APPX.

Changed:
<
<
Another bit of knowledge that is good to have is how printer and form options interact with client-side printing. When you define a printer or form in APPX, you can include options to be passed to the print manager, such as –orientation=portrait, or –pitch=10. These options have nothing to do with the creation of the APPX print file, but are used when the file is printed. With client-side printing, nativeWindows.dll or winprintdll.dll will parse these options from the .cfg file in order to format the appropriate command line to invoke the Windows print manager.
>
>
Another bit of knowledge that is good to have is how printer and form options interact with client-side printing. When you define a printer or form in APPX, you can include options to be passed to the print manager, such as –orientation=portrait, or –pitch=10. These options have nothing to do with the creation of the APPX print file, but are used when the file is printed. With client-side printing, nativeWindows.dll or winprintdll.dll will parse these options from the .cfg file in order to format the appropriate command line to invoke the Windows print manager.
 
Changed:
<
<
It is important to understand that just because you add an option, it does not mean the option will be honored. The APPX dll has a list of recognized options that direct it to format the command for Windows. For a list of those options run winprint.exe from the command line. If you include an option not in that list the dll will pass the command through to the print manager without trying to find a Windows compatible format. Please keep in mind that neither APPX nor the dll do the actual printing. Printing is handled by the Windows print manager. What that means is that even those commands that are recognized in the dll may not give you the results you expect if the printer you selected, or its driver, do not know how to interpret the option. Make sure that any options you may use are identified in the printer’s driver and that the driver is setting the correct control sequence for the command.
>
>
It is important to understand that just because you add an option, it does not mean the option will be honored. The APPX dll has a list of recognized options that direct it to format the command for Windows. For a list of those options run winprint.exe from the command line. If you include an option not in that list the dll will pass the command through to the print manager without trying to find a Windows compatible format. Please keep in mind that neither APPX nor the dll do the actual printing. Printing is handled by the Windows print manager. What that means is that even those commands that are recognized in the dll may not give you the results you expect if the printer you selected, or its driver, do not know how to interpret the option. Make sure that any options you may use are identified in the printer’s driver and that the driver is setting the correct control sequence for the command.
  You should also be aware that the command set in some drivers for direct printing, such as with the client, are not always the same as the options available with interactive printing. If an option you are using works from a desktop application with an interactive print dialog box but not from APPX, consult the driver for the printer to see if the option is supported from the command line.
Changed:
<
<
File permissions is another frequent issue with client-side printing. If the directory where the client places the text and configuration files do not have the correct permissions (read, write, modify or full control) for the user, then client side printing will fail. APPX 4.1.a placed the files in a directory under the desktop client. It is common practice (and the default) to install the client in the c:\Program Files directory and most system administrators do not like to give users permission to write into that directory. The solution is to install the client in another directory where the user has permissions or to set the permissions on the AppxDesktopClient directory to Full Control. The APPX 4.2 engine release avoids that issue by saving the files under the user’s Documents and Settings directory, although some admins will lock that down as well.
>
>
File permissions is another frequent issue with client-side printing. If the directory where the client places the text and configuration files do not have the correct permissions (read, write, modify or full control) for the user, then client side printing will fail. APPX 4.1.a placed the files in a directory under the desktop client. It is common practice (and the default) to install the client in the c:\Program Files directory and most system administrators do not like to give users permission to write into that directory. The solution is to install the client in another directory where the user has permissions or to set the permissions on the AppxDesktopClient directory to Full Control. The APPX 4.2 engine release avoids that issue by saving the files under the user’s Documents and Settings directory, although some admins will lock that down as well.
  Those are some of the basics for client-side printing. With the desktop client, proper printer setup, and proper desktop permissions, you should be able to open up printing to your users wherever they may be located.

Revision 12012-03-20 - ChrisBrower

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="SpotlightTechTips"

Tech Tip - Client Side Printing

by Gary Rogers, APPX Director of Training and Consulting

With the advent of the APPX Desktop Client, a broad range of features were introduced that opened up integration between APPX and the desktop. One of the most useful features is client-side printing. In this issue’s Tech Tip we will explore some of the options and the workings of using client side printing.

In simple terms, client-side printing allows the user to print to a printer defined on the desktop rather than the server. That frees the user from the need to have a connection to the server for printing needs. It opens up printing to any printer at any remote location whether the server where APPX is running can see it or not. Prior to client-side printing all reports were printed from the server. Employees and customers can now access and print reports from home, from the road, or even while at the airport.

It sounds simple enough, and it is. There are only a few of things that need to be done to implement client side printing: 1) Install the Appx Desktop Client. 2) Set one or more printer definitions in APPX for client-side printing. 3) Define one of those printers in the print disposition when creating the report. Do those things and it should just work. Famous last words, right?

Installing the client is easy. On this website ( www.appx.com), follow the menus to Downloads, then Desktop Products. Select the client for your desktop (Windows, Mac, or Linux), save it to disk and install. You can take the defaults for a quick installation. Make sure the listener daemon (appxd, WinAppxD, or AppxDSvc) is set up on your server and connect to Appx using the client.

When setting up a printer for client-side printing, it is as simple as going to the second screen on the printer setup in System Administration and setting the Print to Client flag to Yes (a check mark in the client). You can set up as many client printers as you would like. There are a couple of caveats to this, depending on the release of APPX you are running. Those will be discussed later in this article.

Now you are ready to print to the desktop. All you need to do is place the printer name you set up for client printing in the Printer ID field on the disposition screen or set the name into --- PRINT PRINTER ID work field. APPX does not do anything different to create the report for client side printing. The report and configuration files are created as always and placed in the usual server directory. The report can still be displayed to the screen before printing, and the output can be text or PDF. When APPX goes to actually print the hardcopy things are done a bit differently.

Normally APPX will pass the name of the print and configuration files to the server’s print manager by executing the appx_print script (winprint.exe on Windows), unless the output is PDF. When the printer is set to print to the client, APPX bypasses that process and instead calls an internal routine equivalent to --- SEND FILE TO CLIENT to put the print and configuration files on the user’s desktop. The internal routine for --- LOAD URL ON CLIENT is then executed to pass a command line to invoke the nativeWindows.dll (formerly known as winprintdll.dll). The .dll then formats the info and passes it to the Windows print manager.

As simple as that sounds there are a few other things that are helpful to know about, as well as those caveats mentioned earlier. First, the printer name. When you set up the printer in APPX you can enter an OS printer name in the System ID field. That system ID is then passed to the .dll and on to the print manager to direct the output to the proper printer. When client side printing was introduced, the System ID field was made optional. When left blank, APPX does not pass a printer name and the print manager will send the output to the default desktop printer. That is the most common setup, as this allows pretty much any user to use the default printer ID and have the report print. Prior to APPX 4.2.8, the System ID field was an Alternate Unique key and only one printer could be defined without an ID. From 4.2.8 forward the System ID is now a standard alternate key and you can define as many printers as you would like with no System ID.

If you enter a printer name in the System ID field, APPX will place the name in the configuration file for the .dll to pass to the print manager to use. Here is one of those caveats. The printer ID must be defined as a desktop printer or the file will not print. Also, there was a bug in some of the 4.1.x versions of the winprintdll.dll that would crash the client if the printer could not be found. The fix for that bug is to install an older winprintdll.dll or upgrade to the 4.2.x client. Related to that, if you use a System ID for a client printer, then that printer name must be set up on any and all desktops that will use that printer in APPX.

Another bit of knowledge that is good to have is how printer and form options interact with client-side printing. When you define a printer or form in APPX, you can include options to be passed to the print manager, such as –orientation=portrait, or –pitch=10. These options have nothing to do with the creation of the APPX print file, but are used when the file is printed. With client-side printing, nativeWindows.dll or winprintdll.dll will parse these options from the .cfg file in order to format the appropriate command line to invoke the Windows print manager.

It is important to understand that just because you add an option, it does not mean the option will be honored. The APPX dll has a list of recognized options that direct it to format the command for Windows. For a list of those options run winprint.exe from the command line. If you include an option not in that list the dll will pass the command through to the print manager without trying to find a Windows compatible format. Please keep in mind that neither APPX nor the dll do the actual printing. Printing is handled by the Windows print manager. What that means is that even those commands that are recognized in the dll may not give you the results you expect if the printer you selected, or its driver, do not know how to interpret the option. Make sure that any options you may use are identified in the printer’s driver and that the driver is setting the correct control sequence for the command.

You should also be aware that the command set in some drivers for direct printing, such as with the client, are not always the same as the options available with interactive printing. If an option you are using works from a desktop application with an interactive print dialog box but not from APPX, consult the driver for the printer to see if the option is supported from the command line.

File permissions is another frequent issue with client-side printing. If the directory where the client places the text and configuration files do not have the correct permissions (read, write, modify or full control) for the user, then client side printing will fail. APPX 4.1.a placed the files in a directory under the desktop client. It is common practice (and the default) to install the client in the c:\Program Files directory and most system administrators do not like to give users permission to write into that directory. The solution is to install the client in another directory where the user has permissions or to set the permissions on the AppxDesktopClient directory to Full Control. The APPX 4.2 engine release avoids that issue by saving the files under the user’s Documents and Settings directory, although some admins will lock that down as well.

Those are some of the basics for client-side printing. With the desktop client, proper printer setup, and proper desktop permissions, you should be able to open up printing to your users wherever they may be located.

Comments:

Read what other users have said about this page or add your own comments.



<--/commentPlugin-->
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback