dymodev

I hope everyone enjoyed their holidays! We have had a number of issues reported, several of them were big enough that we decided to release an 8.5.3 patch version that fixes the issues that were found.

Issues Fixed:

Win: There were instances that caused Barcode corruption when the Barcode was rotated on a label

Mac: There were issues with with the Web Service refreshing the list of DYMO printers

Mac: Web Service method timeout is increased due to too many timeouts

JS: Fixed issues with Async calls

JS: Fixed Issue that isBroswerSupported return the wrong value

JS: Fix Issue with a Crash when running in IE8

Reference the following posts for additional set up information. Keep in mind that the Web Service is built into this version of DYMO Label so the standalone install is no longer required.

The JavaScript library is the same as the one posted in the DLS Windows release so the information in the following posts apply to the Mac version of the SDK. Keep in mind that the Web Service is built into this version.

Thanks again for everyone’s patience. We were not able to do a Beta on the Mac version but it contains all the feedback that we got from the Windows Beta. If there are any issues, please either post on the blog or send an email to sdkreply at newellco dot com. We’ll be monitoring both looking for issues and will try to respond to issues as quickly as possible. Keep in mind the more information that you include in your post/email, the better we will be able to help you.

It should be noted that the JavaScript Samples that are in older posts on the blog have not been updated to incorporate the web service correctly.

UPDATE

We’ve had some reports from our users that a reboot may be required for the DYMO Web Service to get properly configured. We are looking into this further. The way you know you are in a state that requires a reboot is as follows:

Click on the DYMO icon in the upper right on the top menu bar

Select Diagnose

If a dialog pops up and it complains about no ssl assigned to the port, you should reboot.

If you see a dialog that says “DYMO Label Web Service is running on port XXX”, then there could be a different issue.

We also know that you are interested in the Mac version. We have had a lot of issues getting the design to work on Mac OSX, we have hit a major milestone this week and we now have a release candidate for DLS 8.5.3 for the Mac. If everything passes, we should be able to release it within a work week.

As a note to all our patient customers, we really appreciate you and your patience. This has been a more difficult release than we had thought but it is finally happening. All we have now is the imminent MacOSX release. Thank you!

Update: Added link to new Javascript library version and added links to older posts for references

We apologize for the length of the delay in this release but we ran into a number of unforeseen issues trying to fix a couple of the bigger issues that were brought to our attention. The two issues that we are addressing in this release are problems with HTTPS and Network Printer discovery.

Requirements

Network Printers

This was a big issue. A service running on windows will not see Network/shared printers for a user and there are Microsoft bugs that prevent seeing these printers when the service is run as the current user. With that in mind, we had to re-implement the way the service is run. It is now a service that starts when the user logs in. This Service will appear in a user’s application tray and can be configured from there. This will allow the SDK to see any Network/Shared Printers that the user has installed.

HTTPS

Our JavaScript library now connects to the web service via HTTPS. We have to install a self-signed certificate to allow this to happen. After installation finishes, we will ask the user if they want to open up the default browser to accept the certificate. Once the certificate is accepted then all HTTPS traffic should work as normal. You can install the certificate on other browsers by going to “https://localhost:/DYMO/DLS/Printing/Check”. This is important for the Firefox browser.

New Tray application

The new tray tool has several options:

Start/Stop the Service

Configure: Which will let you specifically configure a port within the approved range.

Diagnose: This will confirm that the service is running and identify the port.

Notes

The KB2954953 patch no longers needs to be applied for the service to work

We’ve seen some issues where the service needs to run with elevated permissions to see the printers. We are working on this issue.

We’ve seen some crashes when the service starts or at the end of the install. We are investigating but you should be able to start the service from the C:\Program Files (x86)\DYMO\DLS Web Service\DYMO.DLS.Printing.Host.exe

The Mac version is being tested right now and we hope to have a version released soon.

We appreciate your patience! We are working on this as hard as we can and understand your frustrations with delays. We want to insure that we release a quality product that can meet your demands. Your feedback is valuable to us!

We are proud to announce the Open Beta of the new DYMO Label Framework JavaScript Library 2.0. This solution uses a new communication mechanism that will work on all browsers. This means that we have removed the dependency of browser specific plugins like NPAPI and Active-X. The current DYMO Label Framework API is fully supported.

Requirements

The new init method

Since the new communication protocol needs to discover the port that the DYMO service is listening on, a new method was introduced, dymo.label.framework.init(callback). This method performs a scan of a range of ports to look for the DYMO service. This method needs to finish before any other DYMO Framework API calls are made. To accomplish this, the method takes a callback method that will be called as soon as the dymo.label.framework.init method finishes.

Backward Compatibility Mode

If the dymo.label.framework.init method is not called (i.e. no user code has been changed) then the Framework goes into backward compatibility mode. It will try to scan the first port in the defined range and if it finds the service, the new communication protocol will be used. If it fails, it will fall back to the previous implementation that uses native plugins (NPAPI/Active-X).

Tracing

We have added a new tracing feature. This can be used to help debug issues with the new service. The property is called dymo.label.framework.trace. When set to true, it will put tracing messages in the browser developer console. You should set the trace property before calling the dymo.label.framework.init method:

Tracing Example

Known Limitations

The port number that the service binds to is not user definable. We tried to use a range of ports that are not typically used but there could be port conflicts.

HTTPS: Because the service currently uses insecure (http) requests, some browsers may have some issues. For example, Firefox will block insecure XHR requests when a page is loaded through HTTPS. So in order to enable it, the user has to click icon in the address bar and enable insecure requests within a secure connection.

As stated in the requirements, a Microsoft patch is typically required on Windows 8 and greater.

MacOSX support is not included in this Beta, we are working on it now and we will post more news about this version soon.

As with DLS, we do not support Windows Server configurations.

To Do

A new version of the DYMO Label Software 8.5.2 will become available. This version will include the new Framework implementation and will be considered the Release version of the new Framework. This is expected to be released near the end of September.

Service Configuration (Port Number): Currently, the service will bind to the first available port within a given range. We will add a parameter that will allow a user to assign a particular port within the given range.

Investigate the best way to work over HTTPS without issues

We are implementing asynchronous versions of existing API methods

Take constructive feedback and bug reports from our Beta Customers. We will be releasing new versions of the Beta as we respond to issues found in the field.

Update 08/28/2015

If the Web Service fails to install, try and turn off your Anti-virus software before installing.

Update 09/09/2015

We apologize for the delay of the next version of the Beta. We’ve have been working on full HTTPS support, for which testing is ongoing, we found some issues and want to fix them before releasing. We’ve also reproduced the service not recognizing networked printers. We are investigating the possible solutions since it appears to be a limitation of what the service has access to. We’ll keep you informed of any developments.

As many of you know, Google is removing support for NPAPI in the Chrome browser. Our existing JavaScript SDK utilizes this API. We have been diligently working on a new communication mechanism that will work on all browsers and will avoid such things as NPAPI and Active-X and will decouple the SDK from browser specific implementations.

The good news is that we are currently testing our new communication protocol and it will be ready for a Beta release soon.

We have worked hard to make sure that the new SDK will be backwards compatible. There will be the addition of an initialization method, but the existing API works the same.

Our new SDK will utilize TCP/IP to communicate between the browser and a Windows service running on the client machine. The new service will be installed with DLS when upgrading to the new version. A range of ports will be available for our windows service, if the browser cannot bind to one of the ports, it will fall back to our legacy plug-in architecture. For additional security, the service will accept connections only from localhost.
Stay tuned to this blog for more information.

A some may be already aware of, Google has announced that it will phase out support for NPAPI in Chrome with the ultimate removal in Sept 2015. We use NPAPI in the framework for plugin support for most browsers except for IE which we use an ActiveX plugin. We are investigating alternatives to NPAPI but we have not come up with a solution yet.

In the mean time before Sept 2015, you will have to possibly change several settings in your Chrome browser in order to use the DYMO Label Framework:

Click on the Chrome Customize button in the upper right of your browser

Find the Settings option

Click on the “Show Advanced Options” link

Click on the “Content Settings” button or browse to chrome://settings/content

Verify that “Allow all sites to run JavaScript” is enabled

Verify that under Plug-ins that “Run Automatically” is selected

You can check in the “Plug-in exceptions” to see if the site you are running the Framework from is set to “Allow” instead of “Block”

Verify that “Unsandboxed plug-in access” is not set to “Do not allow any sites….”

This should get things working.

Another work around, though less than ideal is to use the extension IE Tab. This will put a web page into an IE browser tab within Chrome and will use the ActiveX plugin instead of the NPAPI version. It has options to add a wild card URL that will automatically use the IE Tab when it matches. We recognize that this is not a valid long term solution.

Update (4/15/2015)
With version 42 of Chrome, Google now disables NPAPI which is required to run our plugin. However, you can manually enable it by typing the following into the Chrome address bar and adjusting the setting:
chrome://flags/#enable-npapi

Update (4/20/2015)
It has been our experience that just enabling NPAPI may not be enough. In some instances, close the chrome browser then uninstall and re-install the DLS software for the plugin to appear in the plugin list: chrome://plugins/
Go here to see if your browser has the framework installed correctly: Check Environement

Update (5/8/2015)
In some situations, a full shutdown and reboot is required after all the steps have been performed for the plugin to appear in Chrome.

Some LabelWriter 450 and 450 Turbo label printers manufactured after April 1, 2014 will not install properly on computers running Windows 7 when connected through a USB 3.0 port. DYMO has a software update available that will fix this problem. For assistance, check here to determine if your label printer is affected and to install the software update. You can also call DYMO Customer Support at 1 (877) 724-8324, Monday-Friday, 8 am – 6 pm (EST).

Because of Firefox’s new release schedule and changes into internal architecture we did one, two, three, four, five updates to the Firefox extension, and another one is coming soon. Again, a note of caution: the extension is obsolete, for new projects use DYMO Label JavaScript library.

The previous post demonstrated different ways of printing QR-code from a .NET application. This blog post will demonstrate how to achieve the same goal from a web application. The complete sample is available here. The corresponding JavaScript is here.

Prerequisites

First, make sure the latest DYMO Label software is installed. It is always available on DYMO web-site, at the time of writing it is version 8.3.1.

Use Barcode Object

The easiest way to print QR-code is to use built-in support for QR-code in DYMO Label Framework. First, design your label using DYMO Label software. Unfortunately, DYMO Label itself does not have ability to specify QR-code barcode type in the UI yet. So, add the Barcode object to the label and put it into desired position. Don’t specify the barcode symbology, use the default Code39. Save the label in to a file, open the file in any XML editor and change thetag to “QRCode”.

First, we check that the label is loaded and the printer is selected. Next, the barcode data is set to be the blog’s URL. And finally, the label is printed.

Use Image Object

Printing QR-code by using Barcode object is easy. The only drawback, it is hard to control the actual barcode size. tag can be used for that but it support only three predefined sizes Small/Medium/Large, but still the overall size will depend on the actual barcode data. The longer the data string, the larger is the barcode. So, the idea is to use some library to generate QR-code image of desired size, and then print it using the Image object. As before, design a label using DYMO Label software. Put an Image object on the label where the barcode should be printed. Set the Image objet size to the desired barcode size. When specifying the barcode image size in pixels calculate it based on the printer resolution, that is 300 dpi for LabelWriter printers and 180 dpi for Tape printers. For example, if you want the barcode to be 1” in size, specify the barcode image size as 300×300 pixels. See BarcodeAsImage.label from the sample project.

Image object accepts image data as a string that contains base64-encoded png stream. The question is, how to get/generate this string. Again, there are several ways of doing that.

Generate and base64-encode QR-code image on the server-side

One way is to generate QR-code image on the server using some library. Then encode the image using base64 and return it to the client as a string. Finally, on the client side, call setObjectText on the Image object and print.

In the sample, we just request “qr.base64” resource that contains precalculated QR-code image for “http://developers.dymo.com”. In real application, you will probably pass the data to be encoded as a resource parameter.

Generate QR-code image on the server-side and base64-encode it on the client-side.

Base64-encoded strings are larger then binary png data. So, to reduce network traffic, we can return original png data from the server and base64-encode it on the client. To encode the data we will create , render our image on it, and then get encoded data using canvas.toDataURL() method.

Note: image loading is asynchronous process. So, we can’t just assign img.src property and immediately draw it on a canvas; we have to wait until the image is loaded completely from the server. To handle that, we do main work in onload handler. also, toDataURL returns data url, to get the data itself, we have to remove the url prefix.

Again, as in the previous case, qr.png resource contains recalculated QR-code image for “http://developers.dymo.com”. In real application, you will probably pass the data to be encoded as a resource parameter.

A drawback of this method is that it requires support in the browser. All major browsers already support it, but be aware that in Internet Explorer it is supported starting from version 9 only.

Use third-party service

Instead of generating QR-code image on your own server, is it possible to use one of the many free online QR-code generator/service? The answer is yes, but it is even more trickier than the previous way. The problem, as usual in web development, is the security. But default is it not possible to grab canvas pixels if an image from a different domain has been drawn on the canvas. It is possible to overcome it, but it requires three parties to participate properly. First, your JavaScript has to set img.crossOrigin property to ‘anonymous’. This will tell the browser that you are trying to access a cross-domain resource, so the browser can send appropriate request headers, e.g. the browser will not send cookies. Next, the server itself should allow its resources to be accessible from other domains. Only few of many QR-code online generators do allow it. And the last, the browser itself should support CORS for . It is very recent addition to the standards, so at the time of writing only Chrome does support it. In any other browsers you will still get “security exception” error. Here are some links regarding and cross-domain limitations:

The code is very similar to the previous example. The only difference is that we set img.crossOrigin property and we use Google’s Infographics API to generate the qr-code image. Notice that in this example the image is generated dynamically, and barcode data is passed as the part of the url.

Pure client-side JavaScript

At the time of writing, it seems there is no self-contained pure JavaScript solutions to create QR-code images using <canvas> completely on the client-side. In the future it might be one more way of doing QR-code printing.

Conclusion

It is quite simple to print QR-code barcode even if built-in support is somewhat limited.