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

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,

Thanks

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

Oh thank you very much! I was implementing QZ Tray for Odoo a few years ago, but I had completely forgotten the name and was painfully itching my head on how to find it again. Can you believe it? :slight_smile: Thanks!

@roquegv What advantages do you see in hardware bridge over QZ Tray?

On the top of my head, I might recall:

  • QZ Tray has no label based printer routing, but rather extension based (is that actually true?)
  • The QZ Tray license, seems hardware bridge is less restrictive?

I just looked at the QZ Tray. It looks nice. It could be enough for your requirements.

It seems to be limited to thermal printers. This could not be a problem. However, if the requirement is to use another kind of printer (eg a laser printer), QZ might not work. So, the main advantage I see of the hardware bridge over QZ is that it could handle any kind of printer.

Both support reading/writing serial ports.

  • QZ Tray has no label based printer routing, but rather extension based (is that actually true?)

Not sure about that.

  • The QZ Tray license, seems hardware bridge is less restrictive?

Yes. MIT license (hardware bridge) is less restrictive than LGPL (QZ)

1 Like

Oh, thank you!

Well, I also checked again more thoroughly and it seems to have pixel printing support indeed: https://qz.io/wiki/2.0-pixel-printing.

It looks like the routing has to be done by the js client:

var config = qz.configs.create("Printer Name");
var data = [{ 
      type: 'pdf', 
      data: 'assets/pdf_sample.pdf' 
}];
qz.print(config, data).catch(function(e) { console.error(e); });

Anyone interested in packaging qz tray for the only true (opinionated speach!) package manager: nix? https://nixos.org

Ah, many thanks for this. I spent ages looking for it. I have installed it now so will see if I can get anything working…

AGAIN…thank you!

You are welcome! :slight_smile: