ScriptX.Services for On-Premise Devices
ScriptX gives developers consistent control of browser-based printing. It is deployed on many millions of client devices worldwide to control the print of billions of documents annually.
ScriptX.Add-on for Internet Explorer uses a deep integration with the Internet Explorer UI and custom templates for the Trident Print engine within Internet Explorer. This enables the Internet Explorer engine to be used to paginate the document and render to the print output device.
The add-on needs to be installed on each client PC - a process that in general requires Administrator privileges and for advanced usage requires a license is accepted and installed by each user of Internet Explorer.
To control the print process the developer writes script code to set required properties on and call methods from the add-on to perform printing and other tasks. Typically the add-on was instantiated with the id 'factory' so code such as this is typical:
As well as working within Internet Explorer we developed ScriptX so that it could be used as an HTML print engine for applications and services such as Internet Information Services (IIS).
In other words, the print technology of ScriptX is tried, tested and used over many years to prove its reliability and robustness.
To support modern browsers on any device with ScriptX.Services we take that technology and deploy it behind a rich Web API on a web server that provides the interface between the ScriptX print engine on the server and the client devices.
The interface accepts a stream of html to print and the settings to use and then passes those onto the print engine which then prints the html with the provided settings such as headers, footers, margins, printer to use, papersize to use and so on.
So, instead of the printing being performed within and by the user's browser, the content to be printed is sent from the client device browser to a server where it is paginated and rendered to a print device connected to the server. If that print device prints to file (e.g. 'Write to PDF' device is used) then the file can be returned to the user where they can print out the content on their local printer.
The anti-polyfill will work with both
'.factory' based code and with MeadCoScriptXJS
Our ScriptX.Services client libraries support Internet Explorer 11, Edge, Chrome, Firefox and Safari and any modern evergreen browser that supports HTML 5 and ECMAScript 5 or later.
ScriptX.Add-on for Internet Explorer continues to be supported for earlier versions of Internet Explorer.
ScriptX.Add-on provides three three ways of printing HTML content from the browser. Each of these functions prints a 'snapshot' of the content as currently displayed in the browser. ScriptX.Services supports each print function.
Print the page/document
window.factoryobject that fully emulates ScriptX.Add-on.
<script src="/scripts/meadco-core.js"></script> <script src="/scripts/meadco-scriptxprint.js"></script> <script src="/scripts/meadco-scriptxprinthtml.js"></script> <script src="/scripts/meadco-scriptxfactory.js" data-meadco-subscription="" data-meadco-server="http://<yourlocaldomain>/<yourOnPremServicesAppName>"> </script>
To be clear; when the 'Print(false)' function executes, the html as displayed on screen is sent (securely over https:) to the server along with references to required external resources such as style sheets and images (script references are not sent). The html document is then re-assembled by the server, paginated and rendered.
The settings such as header and footer are not sent to the server with each setting of a property. The values are stored in variables on the client and then sent to the server with the stream of html to print.
Print a remote document
To print a remote document is simple - send the url to be downloaded and printed to the server along with the required settings. In otherwords, instead of the stream to print, just the url. The server then requests the HTML content from the url then it is paginated and rendered.
Print document fragments
[aka factory.SetPageRange(); factory.Print()]
The SetPageRange() function sets a flag such that only the content that is selected (either programmatically or by the user) is printed. The requirement for a selection means this is not hugely useful, but the ability to print a fragment of or part of the current html document or even a dynamically generated document fragment without the need to copy it into the DOM is useful.
With ScriptX.Services we can easily do this by taking a snap shot of part of the DOM rather then the whole page DOM when printing the whole document. The html is sent (securely over https:) to the server along with references to required external resources such as style sheets and images (script references are not sent). The html is then assembled by the server as a complete document, paginated and rendered.
With our ScriptX.Services libraries you can write the code that works seemlessly with both the ScriptX.Add-on and ScriptX.Services. Whichever browser, which ever device, which ever version of ScriptX, your users will get the same experience with consistent output.
A chance to re-write is always welcome and the very flat properties/methods list of the add-on isn't the design approach that would be taken now.
Our service exposes a rich Web API for describing the parameters to use on the print and delivering the HTML content to print.
- plain text headers and footers,
- landscape or portrait orientation of the paper.
- choosing the paper size to use,
- monitoring of job progress,
- full html headers and footers,
- advanced print scaling.
If you are starting new projects now, then you might want to use your preferred library - jQuery, Angular, React, Vue, Axios etc etc to provide the library for calling a REST API and then extract relevant portions from our libraries on Github for extracting the HTML to send to the service [Swagger API Specification].
The choice is yours.
Advantages of ScriptX.Services
Device and modern browser independence; the host browser and device is not used to to print, print occurs at a server.
Consistent output whatever the client browser. A single print engine is used at the server so the results will always be the same.
There is no requirement to install code on each users PC although note that on our roadmap we have a workstation version of ScriptX.Services which will require installing code on each PC.
There is no requirement for the browser user to accept and install a license - license validation occurs at the server.
Print can only be directed to printers available to the server performing the print. We gain the advantage of being abe to print from any device with any browser; PC, laptop, tablet even phone but this is a significant difference from the Internet Explorer add-on.
At this time we are using the Internet Explorer 11 Trident Rendering engine in 'edge' mode. This is a highly capabable mode with a high degree of compatibility with modern standards HTML as might be required to be printed but clearly there will be some content that cannot be printed or will appear incorrect if it is not supported by Internet Explorer 11 in standards mode.
How to work with ScriptX.Services for On-Premise Devices
So that's the background on the evolution, read on for how to 'deploy' and use ScriptX.Services for On-Premise Devices.