Overall architecture when using Link-OS/Browser Print with a webapp


Our requirements are that we need to use Link-OS/Browser Print in order to communicate with our customers printers (most common is the GK420d). I've got this working with the sample in the installation package.

I'm now wondering about the best approach for putting it all together.

The system is cloud based so all information is stored on "our" servers.

I've read up on ZPL and tested both Zebra Designer and NiceLabel.

Labels will contain lots of dynamic information and from what I can tell, the way to go is to produce the ZPL on the server, send it to the web browser that will then send it to the Browser Print app running on the customers computer.

So there will be either single or multiple labels printed each time.

First question is, are there any drawbacks for using the ^DF command for each ZPL-file created on the server?

Now, the the one thing that took some time to figure out is the step that going from a "template" (*.lbl / *.nlbl) created in one of those applications and then producing pure ZPL which is something that is contained within the respective application.

For instance, trying to handle text overflow will be performed by the application so creating ZPL-code for storing with ^DF command will not have any code for this. The closest I gotten is that NiceLabel can make use of ^FB for doing some alignment towards the borders but I have not found any way for NiceLabel to make use of the ^TB command which is a far better command.

I'm not sure how to formulate a question but just give some backstory to my personal experience with Zebra printer

Right now, I'm leaning towards creating a ZPL-template by hand (read http://labelary.com/viewer.html ),  store that template on our servers, and when a customer would like to print a label, pick up the template, add a bunch of ^XA^FNxxxxxxxx^XZ , send that to the web browser which will send it to Browser Print.

Is there something in this story that stands out as a bad choice?