[Proposal] Faster way to print | Silent Print | Webapp Hardware Bridge

Problem description
To print any document, the following steps are required:

  1. Click the “print” icon. This opens the print view where you can select the print format, etc
  2. Click the “Print” button. This opens the browser’s print windows (after a while) where you can select the printer, etc
  3. Click the “Print” button in browser’s print windows

That is, at least 3 click as required to print any document. This is a pain for many users, especially those who have many printers/print formats.

For example, in the case of a restaurant, there are two printers, one thermal printer for kitchen and another for invoices printing. Each printer needs specific print format. So, in addition to the above steps, the user has to select the print format and then the desired printer. This makes a a total of almost 7 clicks! In this scenario, the printing process is a real pain for users.

Desired solution
The printing process needs to be simplified. Ideally, users have to make just 1 click.

How to make Silent Print
Webapp have their limit when it comes to manipulate user’s hardware (e.i. printer), for security reasons. The only available option browsers give is to print directly, that is, the print windows is not open. In Chrome there is a --kios-printing flag and in Firefox there is a always_print_silent flag.

However, this has it limit. You can’t select the printer you want to send to (at least in a easy way). How to overcome this limit? Well, I came across this tool called Webapp Hardware Bridge. It is basically a Java program that acts as a bridge between the webapp and hardware (printers and serial ports), accepting websocket request. It comes with a configurator in which you can specify which printer will be used according to which label (Print Type) is received (see image).

Captura de pantalla de 2020-12-03 11-13-16

So, the webapp has to connect to the websocket server (bridge), send a request specifing the label (Print Type) and the bridge sends the order to the printer automatically. That is, it could be done in just 1 click!

I already used this tool to print silently, in a scenario in which there are two printers and two respective print formats. The tool works well. However, the code needs some adjustments to cover more scenarios.

I want to contribute this feature to frappe. In order to make the code more general (configurable), I plan to:

  1. Add some fields in Print Format doctype in which specify the labels and the paper size (even witch custom size)
  2. In the print view of any document, include a button to “Print Silently” (which will create a PDF, convert it to base64 and sent it to the bridge throught websocket).

I would like to know what do you think.


Looks interesting. Can you explain the changes in detail? In general this is not a common request (yet) IMO.

Thanks @rmehta for the interest.

The changes are:

  1. Instead of having just A4 and Letter page size for generating the PDF, we could have all the page sizes supported by wkhtml2pdf. In case of Custom page size, we could also set the --page-height and --page-width options.
  2. Instead of having a general setting in Print Setting we could also have the page size option for each Print Format. This is useful because each print format could need specific page size (eg. POS invoice need a smaller size, like B7). In addition to the page size, we could also specify the Print Type (eg. LASER, THERMAL) in order to print with the appropiate printer automatically.
  3. In backend, the get_pdf (in pdf.py) already accepts an options parameter in which to specify the page-size (or page-width and page-height, in case of custom page size). So we could have a method in print_format.py (similar to download_pdf method) in which to set the options and pass it to get_pdf, convert the resulting PDF in base64 (which is the format accepted by the bridge) and return the result to the client (browser). Similar procedure applies in case we want to print many documents at once (as in download_multi_pdf method)
  4. In the frontend, the base64 PDF is received and is send to the bridge to actually print it (using the right printer specified in the Print Format’s Print Type field).

Is that clear?


Sounds great. Looking forward to see this feature!

Can this also work on POS. Especially Chrome that doesn’t allow hiding print preview?

This can be very handy for POS

Thanks for your interest!

@Muzzy, yes, this can work for POS. It’s independent of the browser (just need websocket support, which almost all browsers do).

I wasn’t planning to include this feature for POS, but it is a good idea. Thanks!

I will make a Pull Request within this week, hopefully.

1 Like

Hi there.

How do you run the Java Configurator? Is it in the ‘src’ folder?

I’ve tried everything and looked everywhere on the web to work out how to run it,


How do you install it together with ERPNext?

1 Like

@roquegv Do you have (any unfinished) code for us to take apart?

See also: RfQ: Print ESC/POS on incoming order via USB

@rmehta yet (sic!).

From a first principles process optimization perspective, the lack of direct and versatile printing is unfortunate: ERPnext is perfectly suited for highly customized processes, direct printing is an important part in high volume operations. (Eg. Warehousing)

On the abstraction level of first principles process automation, also related: RfQ: Zeebe.io integration

hi @Oliver_Tsang, sorry for the late response.

In order to install the Webapp Hardware Bridge you should go to the github repository, then Realeases > Assets > download .exe file. Here is the last one: https://github.com/imTigger/webapp-hardware-bridge/releases/download/0.13.0/whb-0.13.0.exe

When installed, you should see the Java Configurator.

Tell me if it works.

1 Like

It should be installed independently in the computer in which you want to print. Here is the installer: https://github.com/imTigger/webapp-hardware-bridge/releases/download/0.13.0/whb-0.13.0.exe

Having that working for a specific project. Unfortunately it is not reusable jet. I should make it more general. The idea is to integrate in the frappe framework or at least publish it as a new frappe app.

Can’t promise a date for this but it is a common request in my context. Should make it soon.

Do you have any specific requirement for this?

Not really, other than the direct printing method beeing exposed on the rest API so the workflow orchestration engine (zeebe) can even help the user save on that last click. :slight_smile:

I’ll be exploring the serial port bidirectional communication to try to leverage an electronic scale to (“silently”) trigger off a business workflow.

Sounds nice.

Yes, the method will be available for the REST API. It will return a base64 representation of the generated PDF and you can do whatever you need with it, normally you will send it to the bridge in order to be printed automatically.

What’s the right way to render raw printing protocols in erpnext? Like ESC/POS or ZPL?

Rendering a pdf (via wkhtml2pdf) is too slow in most of the high volume operations.

Not sure about that.

The bridge gives the option to print in base64, Raw (ESC/POS) and PDF. You can see the demo: webapp-hardware-bridge/printer-basic.htm at master · imTigger/webapp-hardware-bridge · GitHub

As far as I remember, the raw format gave me some problems, so I chose the base64 representation. But it could be good to give a second chance on raw if it can me better in performance.

Does frappe support to render arbitrary bytestrings for documents (instead of html templates)?

Yes, frappe does support client-side Raw Printing with the support of QZ Tray.

1 Like