Technology

ScriptX can be used with any web server that supports the creation of COM components - for example Microsoft's Internet Information Server (IIS) and ASP.NET.

This guide discusses the use of ScriptX with ASP.NET but it is known to work with PHP (and Classic ASP). It is also known that ScriptX can be used within a custom service; we have a number of customers who have successfully deployed services written in .NET and which utilise ScriptX. This guide also applies to such deployments. (For .NET services, please note that ScriptX requires STA apartments and see the notes on ASP.NET deployment).

The Microsoft Windows Web Browsing Platform components are utilised to perform the printing - ScriptX Printing does not contain any actual printing code. Please take note of the caveats Microsoft place around the use of Office Applications as automation servers (for example: HOWTO: Configure Office Applications to Run Under a Specific User Account). Many of these caveats apply to the use of Microsoft Windows Web Browsing Platform components. The components were developed with the intention of a user being present to deal with errors etc. In addition, the Web Browsing Platform utilises WinInet functionality for downloading documents for printing; although this does work in server scenarios, there are limitations. In summary, please be aware of the limitations and set your expectations accordingly but be assured that ScriptX Remote Printing is widely, reliably and successfully used.

On all systems, Distributed COM must be enabled. Customers experience success with "Default Authentication Level" of CONNECT and "Default Impersonation Level" of IDENTIFY; these are the default settings.

Technically, ScriptX printing is implemented as in-process components that provide the API and out-of-process components that implement the actual printing functionality. The out of process components will appear in the Task Manager process list as a process 'MCSXHostxx.exe'.

Session Context

Important: HTML files printed by ScriptX (using PrintHTML) on the server-side are download and printed in a separate process which is absolutely unrelated to the current user's ASP/ASP.NET session context, including any authentication that has occurred by the remote user, either through an authentication dialogue or automatic authentication through, for example, NTLM. If the page to be printed is secured in some way, it must be accessible by the separate process without any user intervention - this may require that automatic authentication is enabled.

The only way to pass any contextual information is via the query part of the URL itself (what follows a question mark).

Internet Explorer Enhanced Security Configuration

Please also note when using Windows Server 2003 and later that Internet Explorer Enhanced Security Configuration may block access to pages you are intending to print, you must ensure that IE ESC is configured appropriately.

::> Mobile printing with ScriptX