Use of QZ tray with Dymo LabelWriter 450

[Erik Huisman]

Dear Sir/Madam,

We are a small company from the Netherlands, that focuses on eCommerce
through the Magento Framework. We've been using the Dymo Label Writers,
as well as Zebra en Brother printers, for quite some time. With the loss
of NPAPI support in browsers, the Dymo Label Framework is insufficient
for printing labels in the near future. Currently we're working on a
module to send print jobs to all these different printers using your QZ
tray application.

We're trying to see if this application is worthwhile, to perhaps
purchase a license in the future. For now there are a few questions we
need to address. The Dymo Label Writers use preset labels, which we have
stored in xml (label) files. Is there a way to load this information
into the application to print the labels vertically, for example? How
can the labels be loaded for the other printers? Is there any place
where we can find extensive documentation on the use of the application?

If there are any questions, please feel free to contact us.

We're looking forward to your reply.

--

Kind regards,

Erik Huisman
er...@aquive.nl

[Tres Finocchiaro]

The Dymo Label Writers use preset labels, which we have stored in xml (label) files. Is there a way to load this information into the application to print the labels vertically, for example? How can the labels be loaded for the other printers? Is there any place where we can find extensive documentation on the use of the application?

Probably not, but this depends entirely on how the XML is processed.

If the XML is processed by the Dymo framework, the burden would be on either us or you to translate that to a standard label format.  We only support a few formats that are universally compatible with Dymo due to the lack of an EPL or ZPL label emulation on some models, so we'd be stuck with appendImage(), appendHTML() or some custom code to simulate the Dymo XML rendering (some of which may be copyrighted, depending on how proprietary it is).

Do you have any technical documentation on the XML standard Dymo is using?

How many templates are you currently using? Would conversion to a different format be possible? 

On another note, we'll be adding HTML5 support near end of year (code to be finished December 2015) so depending on your timeline, we may be able to leverage directly HTML rendering as a future solution, but I'm not sure if the XML templates you already have would be useful or not.

- Tres.Fin...@gmail.com

--
You received this message because you are subscribed to the Google Groups "qz-print" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qz-print+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tres Finocchiaro]

Erik,

Thanks for providing the necessary Dymo Label specifications.

The Dymo Label writers use a specification called "DLS".  From our research this is not a raw format, but rather a format the Dymo API is written to use to translate to a 2D label.  This format appears to be both proprietary as well as copyrighted (which means it may also carry patents).  For this reason we have to be very careful when reverse-engineering the data, which is specified on a Dymo-owned domain "LabelWriter.com" in an XML schema publicly available here: http://www.labelwriter.com/software/dls/sdk/LabelFile.xsd

What options you have:

• As a stop-gap, you may be interested in keeping your existing Dymo templates and leveraging Dymo's beta software, which claims to work with Chrome.  Their blog states HTTPS is not supported yet.  The beta software appears to deploy a print-host service to the PC that allows JavaScript communication with the printer.  If you investigate this route, I would recommend contacting Dymo for more information on what platforms and browsers are supported.
  
  
• Try to get QZ Tray working with your labels as-is.
• We use 100% open source and open-protocols in our code, but some label formats are hard to get working:
• Use our HTML render is extremely limited - not recommended.
  -- OR -- 
• Use our image printing.  This works well if you can rendering your labels server-side (we support appending images as URLs such as https://mysite.com/generateimage.php?foo=bar.
  -- OR -- 
  
• Use our PDF printing. We use an embedded Java render which has some font, palette and general formatting limitations, depending on needs.  Just like images, we support printing the PDF from URL directly or dynamically such as https:??mysite.com/generatePDF.php?foo=bar.
  -- OR -- 
  
• Use HTML5 printing.  This is difficult to setup because we use html2canvas to render the content in an HTML5 capable browser which has several limitations (DPI being one of them).  We do have clients using HTML5 + html2canvas for good quality labels but rendering must be done at a 3x magnification.  We can send a sample if interested.
  
  -- SOME OTHER DETAILS -- 
• We support HTTPS.  As far as we know, we're the first to get this working on Mac, Linux and PC.
• We are upgrading our PDF and HTML renders in December (as well as our single-threaded API) which will allow CSS3 labels to be rendered and printed silently.  Development is underway currently.
  -- FOR RAW PRINTING (ZEBRA, EPSON, etc) -- 
  
• Our raw printing is fast and widely used.  If you decide to leverage raw printing as a stop-gap for your printing needs, ZPL and EPL are common languages that will get the Zebra printer printing thousands of labels very quickly.  (We work with many raw languages, but EPL and ZPL are what we've worked the most with from a label perspective).

I hope this information can help you make a decision.

- Tres.Fin...@gmail.com