Sep 242015

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.


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.


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.


  • 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!

Aug 202015

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.


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).

Init Example

Typical startup code where a method is subscribed to an onload event:

function startupCode() {
    /* access DYMO Label Framework Library */
window.onload = startupCode;

The code should be changed to call a shim that will initialize the DYMO Framework before calling the rest of the startup code.

function startupCode() {
    /* access DYMO Label Framework Library */
function frameworkInitShim() {
    dymo.label.framework.init(startupCode); //init, then invoke a callback
window.onload = frameworkInitShim;


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

dymo.label.framework.trace = 1; //true

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.

Jun 152010


Developing web/browser-based applications might be a hard task. One of the difficulties is that an application is a client-server application. The application consists of the two parts, one runs on the server side inside a web server, another runs on the client side inside a web browser. If a part of the application does not communicate with the external world, e.g. it performs some computation, it might be irrelevant or not very important to understand where it’s running, the server side or the client side. But if the part is communicating with the external world, e.g. it performs printing, it is extremely important to understand the rules and requirements of such communications. To complicate life, modern IDEs and frameworks provide high-level tools and these often hide/abstract core interaction logic between the browser and the server.

The goal for this post is to analyze possible use cases/scenarios related to label printing in web applications. For each scenario the necessary software, installation location, usefulness, etc will be discussed. After reading the post, the readers should be able to answer questions like «Why does my application work great on a development machine, but stop working/crashes/does nothing after deployment?» if awaken in the middle of the night; or even better if such questions will never arise :)

Different Scenarios

In context of label printing the important questions are:

  • Where is the printer connected? On the server or on the client/user machines?
  • Where does the printing happen? On the web server or on the browser?

So, we have four different scenarios.

Printer Connection

User PC


Print From


Scenario #1

Scenario #4

Web Server

Scenario #3

Scenario #2

Lets look at each scenario in detail.

Scenario #1

In this scenario the printer is connected to the client, and printing itself is done on the client/browser. It is a «typical» scenario because is it a classic web-application scenario. The server might be thousand kilometers away; the server cannot access and does not know anything about local label printers installed on users machines. Note: the printer might be not connected directly to the user machine, it might be a «shared» printer on a local network. It is still can be considered as a «local» printer, because it is available from client machine. The point here is that the printer is available from client machine but NOT available from the web server machine.

Server Requirements

There are no special requirements for the server. It might run on any operating system, use any web-server software (like Apache or IIS), etc. Very likely that it will host one or more label files (.label) to be available on the clients.

Client Requirements

Because the printer is connected to the client/user machine, the printer drivers must be installed on the client. Anything else is optional but the most convenient way to do printing is to use the DYMO Label Framework JavaScript Library. In this case DYMO Label software should be installed on the client as well.

Hints for Developers

There should not be code in any language but JavaScript that accesses printing functionality, e.g. there should not be any ASP.NET event handlers those try to create DYMO.Label.Framework or DYMO.DymoAddIn objects.

Load a label file from the server using any AJAX library.

Scenario #2

In this scenario a printer is connected to the server. Printing itself is initiated on the server side as well. Possible types of labeling applications using this scenario are:

  • Some sort of “hard copy” logging. E.g. each operation/transaction is printed on a continuous label roll, like a receipt.
  • In intranet the label printer might be the only one available on the local network, so it might be suitable to connect it on the server.

Server Requirements

Because the printer is connected to the server, printer drivers must be installed on the server. Anything else is optional. If the server is running on Windows the most convenient way to do printing is to use DYMO Label Framework. In this case DYMO Label software should be installed as well. If the server is running on Linux, then you would probably use some PDF library to generate label content then print it using the CUPS API.

Client Requirements

In this case no special/additional software is needed on the client.

Hints for Developers

Check you have no JavaScript code accessing any print related functionality.

Scenario #3

In this scenario the printer is connected locally on the user’s machine but the printing itself is initiated on the web server side. It is really usable only for intranet, because server has to have a connection to a user (all users) printer(s).

Server Requirements

The printer is not physically connected to the server, but printer drivers must be installed on the server because the server has to have a “queue” for the remote client printer. Anything else is optional. If the server is running on Windows the most convenient way to do printing is to use DYMO Label Framework. In this case DYMO Label software should be installed as well. If the server is running on Linux, then you would probably use some PDF library to generate label content then print it using CUPS API.

Client Requirements

Because printer is connected to the client, printer drivers should be installed on the client. Also, the printer itself should be “shared”, so the server can make connect to it and can send print jobs.

Hints for Developers

Check you have no JavaScript code accessing any print related functionality.

Scenario #4

In this scenario the printer is connected to the server, but the printing is initiated from the client. Again it is only usable in intranet/local network setups. Even though, it is hard to think about any good use cases here, because scenario #1 or #2 would be more applicable here. Try to avoid this setup.

Hybrid Scenarios

Of course, some installation might require hybrid scenarios. E.g. your application developed using scenario #1 and works great. Later you decided to add a label preview feature, so user can look at the label before printing. Unfortunately you have to support IE6. But the label preview feature does not in IE6 (it uses data URLs, not supported by IE6). In this case you could modify your setup and install DYMO Label Framework on the server. In this case a label preview can be easily generated on the server and be passed to the client as a regular image URL, not as a data URL.


Developing a web application might be a hard task but it doesn’t have to be. Try to think about your application deployment requirements in advance. Based on that, determine what scenario is the best fit for the application. After that you can think about what should be installed on the server and  client machines and what tools/libraries to use for development.

If you run into a problem, try to determine what scenario your application is using. Knowing that you will know what should be installed in the server and client machines. You might need to rewrite some code if it is placed in a wrong place, that is why it is better to think about it in advance. Don’t hesitate to contact DYMO – we are always glad to help.