Printing without native libraries

[arcadius]

Gathering ideas about how to have this plugin not use any native library.
This would make the plugin easier to manage and releasing on the Google/Apple store would be smoother and one will not need to worry about hardware architecture

Most printers support ,
Raw Port, IPP , AirPrint etc.
So, we should be able to avoid using the native libs provided in the SDK.
The idea is to have your label as an image (HTML canvas -> png) or PDF and send it directly to the printer

This is nothing new and has already been done in:

• https://github.com/RamyTalal/Label-Printer (PHP)
• https://github.com/driehle/node-brother-label-printer (NodeJS)

[robr2112]

One major issue with your proposal is that this would eliminate compatibility with Bluetooth (and USB on Android), since AirPrint/IPP will work ONLY over the WIFI interface.

Another issue is that the printers do not natively support PDF and PNG/JPG, which is why the SDK is needed to convert Image data into data the printers can understand. Though, certainly AirPrint (internally) can convert PDF/Image into the PWG Raster Graphic format used by these "driverless" interfaces, and the printer can handle that.

WARNING: If you use the simplest AirPrint implementation ("printingItem"), this is NOT capable of handling a label that is wider than tall (e.g. 4x3), because Apple AUTOMATICALLY rotates it and completely IGNORES the "orientation" field. So, you would have to implement the most complex API option ("printPageRenderer") if you want to control the orientation.

Also, AirPrint doesn't provide you with a lot of "printer settings" options that can be controlled in app software:

• even something like setting the "halftone" to use to convert your graphic image into 1-bit per pixel data has to be done using the printer's "Embedded Web Server", which is not exactly easy to use.
• And, you can't tell AirPrint what paper size to use, the printer tells the OS what paper size it is configured to use and that's the only option at print-time. (This is maybe less of an issue with QL printers compared to RJ printers, since QL uses keyed paper cartridges so printer knows what's in it. But, RJ and other models need to be configured externally some other way).
• And, if you will support Continuous Roll paper (e.g. receipts), you absolutely MUST implement "cutLengthForPaper" API in order to CALCULATE the length of your job so the printer doesn't feed out 1-3 meters of paper for every page you print.

Plus, Apple is constantly changing AirPrint behavior almost every time they release an OS update. So, your stuff may work one day, and then user updates the OS and now everything is broken (e.g. iOS15 broke a lot of apps that use Continuous Roll paper, and it's still broken at iOS15.5).

And, these are just the iOS issues that come to mind off the top of my head.
Since Google eliminated GCP, I don't know how you would do IPP on Android (not my area of expertise).

So, these "driverless" options may seem like a good idea, but they are extremely limited in functionality compared to the SDK.

Generally speaking, the SDK will be much more "stable", and it will provide access to the full range of printer capabilities, including Bluetooth. Though, it may require regularly updating the SDK included with your plugin, to add support for new printer models, fix issues with OS updates, etc.

Is there a particular problem you are having with the SDK that is causing you to consider going down this road?

Best regards,
Rob

[arcadius]

Hello @robr2112
Thank you very much for your elaborate response.
I do understand that there is a place for the native SDK, as it exposes all of the functionalities available on the Brother label printers. I do understand that.

However, there is a need for a lighter SDK.
In my situation, I have an app that is currently on Android and iOS.
I want to port it to Windows desktop, Mac, Linux, chromebook.

My whole system is fully portable and platform agnostic except the brother printer SDK.

It would be great if the printer SDK was written in javascript without native dependencies.

You mentioned that we need the possibility to issue a "cutLengthForPaper" command.
That is very true ....
And when you think about it, you will realise that when one loads a continuous label in the printer, one may want to turn on
label cutting on by default.

Most App developers just want to format the data and send it out to the printer.

Note that a customer of mine pointed me to DYMO ... they have a JavaScript fully portable SDK:
https://github.com/dymosoftware/dymo-connect-framework

I suppose Brother could do better and offer a more portable SDK ...

[robr2112]

Hi @arcadius,
Thanks for your detailed reply. Sorry for late response.

I understand what you are saying!!
I see the Dymo solution requires a companion app to be installed on iOS/Android device in order for their "JavaScript SDK" to work. Unfortunately, we do not have a similar solution yet. But, stay tuned....

And when you think about it, you will realise that when one loads a continuous label in the printer, one may want to turn on
label cutting on by default.

I'm 99% sure there is a way to enable this as default behavior for printers that have a cutter. It may require sending a specific command or using a tool like Printer Setting Tool to set it as power-on default setting. Otherwise, the SDK will send a run-time command that is not "persistent", to enable the cutter options for that job only. AirPrint however does not provide any way to set these types of settings. That's one of the major problems with these "driverless drivers", as I said before. Anyway, if you really want to know how to enable this specific thing, we can chat more about it and I will try to verify the final 1%. But, I don't think that's the main topic here. ;-)

Most App developers just want to format the data and send it out to the printer.

The "format the data" part is a can of worms, because each printer vendor/model has different languages and capabilities. There are some printer "languages" that are common to most vendors, at least as emulation. But, these languages may not necessarily be friendly to a typical JavaScript developer. And, most printers are not able to decode PDF or PNG.
The "send it out to the printer" part is also problematic in a cross-platform situation, since I/O is generally dependent on the native OS. Bluetooth in particular has some OS and vendor dependent things, like the "MFi protocol string". WIFI has these IPP/AirPrint protocols that are more device independent, as you indicated. But, IPP is limited as concerns printer settings and options. So, there's always a trade-off.

Ultimately, you need to use a development tool that checks all the boxes for your situation. And, it's up to us to try to keep up with all the different tools used by all the different developers, and try to provide solutions for all of them. It's a challenge for sure. But, we're trying as best we can!! Hopefully we can provide a solution that fits your need mentioned here. I just can't promise anything.

Anyway, thanks for providing and maintaining this plugin that is based on the SDKs.
I know it is helpful to the Cordova developer community and to Brother.

Cheers,
Rob