Modern web browsers have been designed to protect end-users from malicious or unwanted access to computer’s local resources. Typically, web browsers have none or limited access to disk units, USB devices and peripherals devices attached to the local computer.
Local printers are not an exception; they are restricted to printing web content only. Previously we had a workaround to print a PDF, you can check the article here. But what if our VirtualUI-enabled application needs to send raw print commands and data to a matrix or label printer such as Zebra, Epson, etc.?
This article will demonstrate how to access a printer connected to the web browser from our application so we can generate RAW prints remotely as if the remote application and the printer were available in the same environment.
The following scheme roughly illustrates the requirement we want to fulfill:
The web-enabled application is executed remotely and we access it through the web browser. At the same time, there is a local printer to which we can print from the web browser, but which is not visible from the “webified” application.
So, we must create a bridge between both parts, making the application know which printers are available for use from the web browser and, when the application generates and sends printing packets, we must take them and send them to the printer, while also returning its latest status to the application.
To do this, we need to create the two parts of the bridge: a communication channel to transfer the printing data from the application to the browser, and another communication channel to transfer data from the web browser to the printer.
Building the Bridge to the Printer
The First Part of the Bridge
VirtualUI allows for the use of remote Windows applications through their graphics interface virtualization.
Unfortunately, the printing commands are not part of this virtualization, since they are not visible elements that can be taken to the remote interface (the web browser) in the same way that a button or editable field can.
For these cases, where the GUI virtualization provided by VirtualUI is not enough, there is jsRO.
jsRO is a VirtualUI extension created to establish a bidirectional communication channel between the application and the web page. jsRO’s core is the creation of remotable objects by code in the application. these remotable objects are then replicated in the web page as native Javascript objects. The communication between these objects is so intimate that both behave as a single entity, which allows both environments to keep a communication channel synchronized at all times in addition to the remote interface visualization.
To trigger and control the printing from the application, then, we will create a jsRO object, which will keep the communication between the application and the browser synchronized to interact with the remote printer.
The Second Part of the Bridge
To establish the connection with the printer, we will use a small printer connection server called QZ Tray, which allows us to connect to local printers from a web client using the serial or USB port. The communication with QZ Tray from the web client requires the inclusion of a couple of Javascript libraries: qz-tray.js, which implements the communication with QZ Tray and enables the printing from Javascript; and qz-app.js,which implements the jsRO Javascript part and talks to the QZ Tray Javascript component to complete the communication circuit.
The following graph shows the complete communication scheme in detail:
3 Comments
Interesting. But where do I find the javascript files it talks about?
Hi Michael,
Please send us an email to [email protected] and we’ll send you all the nescesary tutorials to set up your deployment.
Kind regards.
Hi there ! Very nice article. Why there are not the part 2 of it ?