All printing with ScriptX is asynchronous.
With ScriptX.Services requests are sent using the http: protocol to a server that processes the request and performs the print - commonly known as AJAX calls to a REST api. This processing is asynchronous.
This sample assumes that the MeadCoScriptXJS and MeadCo ScriptX.Services print client modules libraries are in use to enable the same code to be written for both Add-on (Internet Explorer) and ScriptX.Services (any modern/evergreen browser). The sample illustrates the changes that must be made to older code that worked with the Add-on only to support use in any browser.
Each of the functions Print, PrintHTML and BatchPrintPDF will return immediately after the print request has been queued with the print occuring later at the ScriptX.Services server. The browser remains responsive and so the user can close the tab/window while the print is in progress. Please note that printing does not start immediately after the called print function returns. There is a short queue on the client side which will delay the sending of the job to the server where it is also queued for printing. If the window/tab is closed before being sent, the job is lost completely.
Unlike with the Add-on, closing a tab/window after printing has started (sent to the server) does not cause the print to be abandoned - the print will continue and no warnings will be given to the user.
If a print is being performed to file for download by the client device and the client browser tab/window is closed then the print will complete at the server but will be uncollected and so 'lost'.
The use of OwnQueue() with ScriptX.Services is a no-op as, to all intents and purposes all printing occurs in a separate 'process'.
Use printer:
The ScriptX.Add-on WaitForSpoolingComplete function enables synchronous javascript code to be written so that actions can be taken safely once all printing has completed.
For example navigate to another page or close the current window:
// Queue all of the documents in the array for printing, wait for printing // to be spooled to the printer and then redirect to the given url function PrintDocumentsAndClose(docUrls,afterPrintRedirect) { docUrls.forEach(function(doc) { log("Request print of: " + doc); MeadCo.ScriptX.Printing.PrintHTML(doc, false); }); MeadCo.ScriptX.Printing.WaitForSpoolingComplete(); window.location.href = afterPrintRedirect; }
WaitForSpoolingComplete also enables a busy UI to be implemented very easily. For example, a progress indicator can be shown and hidden:
// a simple show a busy indicator while printing. function ShowPrintBusy() { $("#printBusy").show(); MeadCo.ScriptX.Printing.WaitForSpoolingComplete(); $("#printBusy").hide(); }
The code illustrated above will not work as expected with ScriptX.Services.
MeadCo.ScriptX.Printing.WaitForSpoolingComplete() is implemented in javascript but it will return immediately. It is not possible to write blocking functions in javascript that can monitor asynchronmous processes.
The code updates required are reasonably minimal. Instead of using MeadCo.ScriptX.Printing.WaitForSpoolingComplete() use MeadCo.ScriptX.WaitForSpoolingComplete() from the MeadCoScriptXJS library instead. This function returns a promise:
// Queue all of the documents in the array for printing, wait for printing // to be spooled to the printer and then redirect to the given url function PrintDocumentsAndClose(docUrls,afterPrintRedirect) { docUrls.forEach(function(doc) { log("Request print of: " + doc); MeadCo.ScriptX.Printing.PrintHTML(doc, false); }); MeadCo.ScriptX.WaitForSpoolingComplete().then(function() { window.location.href = afterPrintRedirect; }); }
A busy UI is also simple to implement by extending the original implementation:
// a simple show a busy indicator while printing. function ShowPrintBusy() { $("#printBusy").show(); MeadCo.ScriptX.WaitForSpoolingComplete().then(function() { $("#printBusy").hide(); }).catch(function() { $("#printBusy").hide(); }); }
Note that there are 'cascading' consequences to there being no true blocking but asynchronous function. If you have code that calls a similar function to ShowPrintBusy() but that code assumes that ShowPrintBusy() will not return until printing is complete then you will need to add a callback argument. For example:
// a simple show a busy indicator while printing and then call a function when print has completed. function ShowPrintBusy(fnCallBack) { $("#printBusy").show(); MeadCo.ScriptX.WaitForSpoolingComplete().then(function() { $("#printBusy").hide(); fnCallBack(); }).catch(function() { $("#printBusy").hide(); }); }
In these samples we use this technique but also show a dialog to disable any on page user interface.
Emulations in javascript of the system Pagesetup and Print dialogs are provided by the MeadCo ScriptX.Services print client modules library. This library is used by MeadCoScriptXJS to implement prompted printing. However, these functions are asynchronous so the return value (i.e. did the user elect to print) is not available.
A small code change is required.
From:
if ( MeadCo.ScriptX.PrintPage(true) ) { ShowPrintBusy(); }
To:
MeadCo.ScriptX.PrintPage2().then(function(bAccepted) { ShowPrintBusy(); });
The code changes above will also work with the Add-on - the MeadCoScriptXJS library hides the differences between implementations.
ScriptX.Services enables the consistent printed formatting and appearance of browser‑based content. It is our evolving cross‑browser solution, printing across the cloud and to printers connected to individual PC workstations or to on‑premise servers.
Many of our users told us that they wanted to use ScriptX's unique printing functionality in other browsers and on other platforms and devices.
ScriptX.Services is an evolution which continues to provide developers with the tools to ensure the consistent formatting and appearance of printed output regardless of a user's choice of device or browser. So for example, labels or badges can now be printed from a browser on a smartphone or tablet to a specified printer on an intranet.
To support today's browsers on any device, with ScriptX.Services we take the technology of ScriptX.Add‑on and deploy it behind a web API on a Windows server which can be running on the user's PC, on an intranet or on the public internet “in the Cloud”.
The interface accepts a stream of HTML to print and the settings to use and then passes those onto the print engine, which in turn prints the HTML to the specified or default printer with the settings provided such as headers, footers, margins, printer, paper size and so on. The HTML to be printed could be the current page in the browser but could also be HTML generated by scripting on the page or even HTML from a different URL entirely. Printing of PDF documents is also supported.
Promptless printing - as printing is carried out via the ScriptX.Services API, the browser's print dialog will not be shown, preventing users from inadvertently using settings that prevent a document from printing as intended. Alternatively developers can create their own print dialog using our freely available javascript libraries or hand-crafting a purposed, customised dialog or popup.
Please take a look at our introduction and guide which demonstrates how straightforward it is to incorporate ScriptX.Services into your existing web applications and take control of your printed output. The guide also discusses how existing ScriptX licensees using our MeadCoScriptXJS javascript wrapper library for ScriptX.Add‑on can easily modify their web applications to use ScriptX.Services. Click here for a walk-through illustration of converting a web page.
Many of our users told us that they wanted to use ScriptX's unique printing functionality in other browsers and on other platforms and devices.
ScriptX.Services is an evolution which continues to provide developers with the tools to ensure the consistent formatting and appearance of printed output regardless of a user's choice of device or browser. So for example, labels or badges can now be printed from a browser on a smartphone or tablet to a specified printer on an intranet.
To support today's browsers on any device, with ScriptX.Services we take the technology of ScriptX.Add‑on and deploy it behind a web API on a Windows server which can be running on the user's PC, on an intranet or on the public internet “in the Cloud”.
The interface accepts a stream of HTML to print and the settings to use and then passes those onto the print engine, which in turn prints the HTML to the specified or default printer with the settings provided such as headers, footers, margins, printer, paper size and so on. The HTML to be printed could be the current page in the browser but could also be HTML generated by scripting on the page or even HTML from a different URL entirely. Printing of PDF documents is also supported.
Promptless printing - as printing is carried out via the ScriptX.Services API, the browser's print dialog will not be shown, preventing users from inadvertently using settings that prevent a document from printing as intended. Alternatively developers can create their own print dialog using our freely available javascript libraries or hand-crafting a purposed, customised dialog or popup.
Please take a look at our introduction and guide which demonstrates how straightforward it is to incorporate ScriptX.Services into your existing web applications and take control of your printed output. The guide also discusses how existing ScriptX licensees using our MeadCoScriptXJS javascript wrapper library for ScriptX.Add‑on can easily modify their web applications to use ScriptX.Services. Click here for a walk-through illustration of converting a web page.
Many of our users told us that they wanted to use ScriptX's unique printing functionality in other browsers and on other platforms and devices.
ScriptX.Services is an evolution which continues to provide developers with the tools to ensure the consistent formatting and appearance of printed output regardless of a user's choice of device or browser. So for example, labels or badges can now be printed from a browser on a smartphone or tablet to a specified printer on an intranet.
To support today's browsers on any device, with ScriptX.Services we take the technology of ScriptX.Add‑on and deploy it behind a web API on a Windows server which can be running on the user's PC, on an intranet or on the public internet “in the Cloud”.
The interface accepts a stream of HTML to print and the settings to use and then passes those onto the print engine, which in turn prints the HTML to the specified or default printer with the settings provided such as headers, footers, margins, printer, paper size and so on. The HTML to be printed could be the current page in the browser but could also be HTML generated by scripting on the page or even HTML from a different URL entirely. Printing of PDF documents is also supported.
Promptless printing - as printing is carried out via the ScriptX.Services API, the browser's print dialog will not be shown, preventing users from inadvertently using settings that prevent a document from printing as intended. Alternatively developers can create their own print dialog using our freely available javascript libraries or hand-crafting a purposed, customised dialog or popup.
Please take a look at our introduction and guide which demonstrates how straightforward it is to incorporate ScriptX.Services into your existing web applications and take control of your printed output. The guide also discusses how existing ScriptX licensees using our MeadCoScriptXJS javascript wrapper library for ScriptX.Add‑on can easily modify their web applications to use ScriptX.Services. Click here for a walk-through illustration of converting a web page.
Many of our users told us that they wanted to use ScriptX's unique printing functionality in other browsers and on other platforms and devices.
ScriptX.Services is an evolution which continues to provide developers with the tools to ensure the consistent formatting and appearance of printed output regardless of a user's choice of device or browser. So for example, labels or badges can now be printed from a browser on a smartphone or tablet to a specified printer on an intranet.
To support today's browsers on any device, with ScriptX.Services we take the technology of ScriptX.Add‑on and deploy it behind a web API on a Windows server which can be running on the user's PC, on an intranet or on the public internet “in the Cloud”.
The interface accepts a stream of HTML to print and the settings to use and then passes those onto the print engine, which in turn prints the HTML to the specified or default printer with the settings provided such as headers, footers, margins, printer, paper size and so on. The HTML to be printed could be the current page in the browser but could also be HTML generated by scripting on the page or even HTML from a different URL entirely. Printing of PDF documents is also supported.
Promptless printing - as printing is carried out via the ScriptX.Services API, the browser's print dialog will not be shown, preventing users from inadvertently using settings that prevent a document from printing as intended. Alternatively developers can create their own print dialog using our freely available javascript libraries or hand-crafting a purposed, customised dialog or popup.
Please take a look at our introduction and guide which demonstrates how straightforward it is to incorporate ScriptX.Services into your existing web applications and take control of your printed output. The guide also discusses how existing ScriptX licensees using our MeadCoScriptXJS javascript wrapper library for ScriptX.Add‑on can easily modify their web applications to use ScriptX.Services. Click here for a walk-through illustration of converting a web page.
Many of our users told us that they wanted to use ScriptX's unique printing functionality in other browsers and on other platforms and devices.
ScriptX.Services is an evolution which continues to provide developers with the tools to ensure the consistent formatting and appearance of printed output regardless of a user's choice of device or browser. So for example, labels or badges can now be printed from a browser on a smartphone or tablet to a specified printer on an intranet.
To support today's browsers on any device, with ScriptX.Services we take the technology of ScriptX.Add‑on and deploy it behind a web API on a Windows server which can be running on the user's PC, on an intranet or on the public internet “in the Cloud”.
The interface accepts a stream of HTML to print and the settings to use and then passes those onto the print engine, which in turn prints the HTML to the specified or default printer with the settings provided such as headers, footers, margins, printer, paper size and so on. The HTML to be printed could be the current page in the browser but could also be HTML generated by scripting on the page or even HTML from a different URL entirely. Printing of PDF documents is also supported.
Promptless printing - as printing is carried out via the ScriptX.Services API, the browser's print dialog will not be shown, preventing users from inadvertently using settings that prevent a document from printing as intended. Alternatively developers can create their own print dialog using our freely available javascript libraries or hand-crafting a purposed, customised dialog or popup.
Please take a look at our introduction and guide which demonstrates how straightforward it is to incorporate ScriptX.Services into your existing web applications and take control of your printed output. The guide also discusses how existing ScriptX licensees using our MeadCoScriptXJS javascript wrapper library for ScriptX.Add‑on can easily modify their web applications to use ScriptX.Services. Click here for a walk-through illustration of converting a web page.