Aug 082016

Working with DYMO Label Web Service

Download Word Version of this post

Download PDF Version of this post

What is the DYMO Label Web Service?


In the past, developers had to provide a browser-specific plug-in for each major web browser.  Nowadays, most browsers have phased out native plug-in support.  Google, for example, stopped supporting Chrome their NPAPI browser extension in September 2015.  In response, we released the DYMO Web Service as a new cross-browser solution allowing third-party developer applications the ability to interface with the DLS SDK in a seamless, browser-agnostic fashion.  It handles all printer-related requests from the JavaScript Library that the DYMO Label Framework browser plug-ins used to perform.

(For more information on the framework, please visit


How do I install the DYMO Label Web Service?


First, download the appropriate installer for your OS.  You can find them at the following URL:



Double-click on the installer and follow the directions provided by the install wizard.


Double-click on the DMG file to mount it.  Select the newly mounted volume and double-click on the PKG file found within it.  Then follow the directions provided by the install wizard.

How can I tell if I have DYMO Label Web Service installed?


The DYMO Label Web Service is installed as long as you have installed DYMO Label Software 8.5.3 or newer using the express “Express” mode.

If you choose to install DYMO Label Software in “Custom” mode, be sure to select the DYMO Label Web Service component as follows:


Custom select components to install







If installed, there will be an executable file named DYMO.DLS.Printing.Host.exe within the DLS working folder (normally found within the C:\Program Files (x86)\DYMO\DYMO Label Software folder on Windows and the /Library/Frameworks/DYMO/SDK folder on Mac).



Executable location (Windows)

Executable location (Windows)


How can I tell if the DYMO Label Web Service is running?

You should see the DLS application icon within the system tray.  Right-click this icon to display a context menu.  The menu displays the web service’s status (i.e., “Started on port 41951” or “Stopped”).

The following shows what it looks like on Windows.

DLS icon and context menu (Windows)

DLS icon and context menu (Windows)


On Mac, the DLS application icon and context menu will appear within the system tray like this:

DLS icon and context menu (Mac)

DLS icon and context menu (Mac)

I do not see it in the system tray.  How can I start it?



You can start the web service again by navigating to the DLS working folder and running the executable named DYMO.DLS.Printing.Host.exe.


Open a Finder window, navigate to the /Library/Frameworks/DYMO/SDK/ folder, and click on the icon.

Open a terminal prompt and enter the following command:

launchctl start com.dymo.dls.webservice


How can I start or stop the DYMO Label Web Service?

You can start or stop the web service at any time by open right clicking on the service’s icon in the system tray and choosing the Start service and Stop service menu items, respectively.  Although API functions will not execute after stopping the service, the service icon will remain in the system tray after stopping it.


How can I configure the DYMO Label Web Service?


Clicking the Configure menu item will cause a configuration window to appear.  This allows you to change the language and listening port.  The web service will normally try to use the first available port within the 41951-41960 range.  You can override this behavior by checking the Use single port checkbox, which makes the service only try using the specified port only. You cannot specify a port number that does not fall within the specified range.  The service will not try using any other port if an error occurs while using this option.

Web Service configuration dialog (Windows)

Web Service configuration dialog (Windows)



Web Service configuration dialog (Mac)

Web Service configuration dialog (Mac)



How can I tell if the DYMO Label Web Service is functioning properly?

Click the Diagnose menu item within the context menu while the service is running.  If the self-test succeeds, a dialog box will appear asking you to open a test page in your browser to see if SSL certificate is working.


Diagnose successful (Windows)

Diagnose successful (Windows)

Diagnose successful (Mac)

Diagnose successful (Mac)


Click the Yes button to open your default web browser.  The browser should display a page indicating the web service is running correctly.  The page address should be something to the following effect:


The port number may vary from machine to machine.


Web Service is up and running configuration

Web Service is up and running configuration


How do I use the DYMO Label JavaScript Library?


Getting Started

You need to link to the DYMO Label Framework’s JavaScript library in order to use the DYMO Label Web Service via web pages.  You accomplish this by using the following code snippet:

 <script src="dymo.label.framework.js" type="text/javascript" charset="UTF-8"></script>

Your code then needs to call the following initialization method while providing it a callback to be invoked by the library when initialization completes:


The library invokes this callback whether or not initialization completes successfully.


Do I need to change my code to work with the new DYMO Label JavaScript Library?

Although it may work with old unmodified code in some cases, it is highly recommended to make a few changes to avoid future problems.

The biggest change to the JavaScript Library is the move from a synchronous architecture to an asynchronous one.  This move has several advantages, improved UI responsiveness and shorter discovery time while scanning the available port range.  Synchronous AJAX calls are already marked deprecated in most major web browsers, so we recommend switching to asynchronous JavaScript Library initialization as soon as possible.


What will happen if I leave my old code unchanged?

If you do not update your code to make use of asynchronous calls, the JavaScript Library will fall back to the synchronous behavior upon accessing the library for the first time when a page is loaded.  It will synchronously try to scan the first port.  This is either the default port or the last known working one (i.e., the cached port number).  The library will use web service-based functionality if it successfully connects to the port.  Otherwise, it will fall back to using native plug-ins.  All subsequent calls to the library will continue to reuse whatever method succeeded until you reload the page.


What do I need to change in my code to make it properly work with new the JavaScript library?


The library now makes use of a new initialization method to perform asynchronous initialization through use of a callback method.  Since the library performs initialization in the background, calling an SDK function prior to initialization results in an error.  Your code should be updated to call the new dymo.label.framework.init() method while providing it a callback to be invoked by the library when initialization completes.  Please note the library invokes this callback whether or not initialization completes successfully.

Any code initialization involving calls to the JavaScript Library is typically located inside an event handler (i.e., window.onload).  Below is typical JavaScript code demonstrating how to do this with the old synchronous architecture:

function startupCode() {
/* access DLS SDK */

window.onload = startupCode;

This code will not work correctly under the new asynchronous architecture.  It should be changed to call an intermediate “helper” method that firsts calls new init() method accepting your callback as a parameter.  The library invokes the callback containing your original startup code after library initialization completes.  Below is the updated JavaScript code that uses asynchronous initialization:

function startupCode() {
/* access DLS SDK */
function frameworkInitHelper() {
// init, then invoke a callback


window.onload = frameworkInitHelper;

If initialization is asynchronous, are other methods asynchronous as well?

The short answer is, “Yes!”  As stated previously, synchronous AJAX requests are deprecated, so our new JavaScript library contains new asynchronous equivalents for every method that calls the web service.  These methods have the same names as their counterparts in the former architecture along with the Async suffix appended to them.  They take the same number of parameters with corresponding types as well.  The only major difference is that the new methods return a Promise object instead of the actual return value.  You make use of this object by providing its then() method your callback function and one argument which receives the actual return value when the asynchronous method completes.

 dymo.label.framework.getPrintersAsync().then(function(printers) {
// printers list (same list the getPrinters() returns)


How do I make use of Promise objects in asynchronous programming?

Asynchronous JavaScript programming is not covered here. Please refer Google’s documentation on Promise object usage and errors handling:

How can I tell if the JavaScript library is currently using the web service?

The dymo.label.framework.checkEnvironment() method returns a CheckEnvironmentResult object along with multiple parameters (please refer to existing documentation on checkEnvironment() method).  The new JavaScript library contains an additional property within this object called isWebServicePresent.  You can use this property to determine if the web service is actually used.

As with all other SDK-related methods, do not call checkEnvironment() until init() finishes initializing. Synchronous library initialization and web service discovery will occur if it is called before init() completes.

Basic Service API Functions


The following is a list of basic API functions provided by the DYMO Label JavaScript Library.


Purpose:  Returns a list of installed DYMO printers
Parameters:  None.

printers = dymo.label.framework.getPrinters();
for(var i = 0; i < printers.length; i++)
var printer = printers[i];


Purpose:  Returns a document object model (DOM) for label file.

labelUri – label file Uri


 var labelUri = "file:///Volumes/DATA/DieCut.label";
var label = dymo.label.framework.openLabelFile(labelUri);


It is necessary to use the label.getLabelXml() or label.toString() functions to obtain XML representations of a label.


dymo.label.framework.renderLabel(labelXml, paramXml, printerName)


Purpose:  Returns a graphic representation of the label (PNG) encoded in base64 format.

labelXml – DOM or XML representation of the label

paramXml – render parameters

printerName – printer name


 var image = document.createElement('img');
var labelXml = dymo.label.framework.openLabelFile(labelUri).getLabelXml();
var pngData = dymo.label.framework.renderLabel(labelXml, "", printerName);
image.src = "data:image/png;base64," + pngData;

dymo.label.framework.printLabel(printerName, paramXml, labelXml, labelSetXml)


Purpose:  Prints a label on the specified printer.

printerName – printer name

paramXml – printing parameters

labelXml – DOM or XML representation of the label

labelSetXml – data set for label objects


 var paramsXml = dymo.label.framework. createLabelWriterPrintParamsXml ({ copies: 2 });
var labelSetXml = new dymo.label.framework.LabelSetBuilder();
var record = labelSet.addRecord();
record.setText("Address", "Test Address String");
dymo.label.framework.printLabel(printerName, paramsXml, labelXml, labelSetXml);




What is Trace functionality?

Our JavaScript Library now includes trace functionality that may help you debug your code.  You can enable it by adding the following code vline before calling the init() method:

dymo.label.framework.trace = 1;

When using this code, you will see which steps the library takes every time it attempts to initialize (i.e., synchronous vs asynchronous initialization, port number if web service is discovered, fallback implementation selection, etc.).

Below is sample trace output when init() is called and the web service is present:

checkEnvironment > cachedWebPort : 41951
checkEnvironment > trying async service discovery
_createFramework > return _framework : undefined (async)
onEnvironmentChecked > checkResult isBrowserSupported : true, isFrameworkInstalled: true, isWebServicePresent: true
chooseEnvironment > WebServicePresent

The following is an example for case when init() is not called but the web service is running (fallback mode for legacy user code):

checkEnvironment > cachedWebPort : 41951
checkEnvironment > trying sync service discovery
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user’s experience.
checkEnvironment > web service found at port :41951
onEnvironmentChecked > checkResult isBrowserSupported : true, isFrameworkInstalled: true, isWebServicePresent: true
chooseEnvironment > WebServicePresent

This sample output demonstrates the case when the web service is not running (fallback mode for legacy plug-ins).  Here the init() method was called; not calling the init() method will eventually lead to same fallback behavior but will additionally result in a hung UI during the initialization phase):

checkEnvironment > cachedWebPort : undefined
checkEnvironment > trying async service discovery
_createFramework > return _framework : undefined (async)
checkLegacyPlugins > WIN platform
checkLegacyPlugins > non-IE
checkLegacyPlugins > ‘application/x-dymolabel’
onEnvironmentChecked > checkResult isBrowserSupported : true, isFrameworkInstalled: true, isWebServicePresent: false
chooseEnvironment > WIN


How do I perform error logging?

Improper DYMO Label SDK usage or multiple unexpected external factors may result in errors.  You may need to retrieve logging data in these cases to help resolve problems.

Network and web service errors

To see communication errors and service fault messages, you will need to open Developer Tools (invoked by F12 key in most browsers) and open “Network” tab. If you see erroneous response in the list, you can click it and look for details in adjacent window (look and position is browser-specific). Response body would normally contain error description.

Web service log

The log file is located at %LocalAppData%\DYMO\DLS8\DLSWebService.log

If you are performing some specific tests, we recommend you delete the existing log before making a test run to eliminate any unnecessary log messages.

Jan 022014

There is currently a bug in Windows 8.1 that causes any label with a barcode to print abnormally in DLS. We are awaiting a fix from Microsoft, but in the meantime, you will need to modify a setting in DLS to workaround the issue. To do this, go to Edit -> Preferences. Navigate to the LabelWriter printer tab and change the “Print Quality” to “Text”.


There is one side effect to making this change and that is your labels will always print at a resolution of 300×300 DPI. For barcodes, we typically like to switch our printers into high resolution mode (300×600 DPI) in order to improve barcode scanning reliability. When the “Print Quality” setting is set to “Auto” or “Barcodes and graphics”, the resolution will always be 300×600 if a barcode is present on your label. That being said, for most barcodes, 300×300 DPI is plenty of resolution. You may encounter scanning issues for barcodes with lots of data or 2D barcodes, though.

We apologize for this inconvenience and will keep everyone updated on a fix for this issue.

Microsoft has released a fix for this issue. It can be downloaded from the below links. Thanks Bjorn for the heads up!

KB2911106, released on 13/01/2014, solved this issue in Windows 8.1
Download x86 :
Download x64 :

Aug 142013

Hello everyone,

We thought it would be helpful to have sort of an “interactive” post where you could ask questions about our SDKs. Here’s how it will work:

  • Add a comment to this post asking any question you like regarding DYMO SDKs. It can be anything: how to setup a simple SDK application, potential bugs you may have encountered, etc.
  • We will sort through your questions and pick a some of the best ones to answer in this post.
  • This post will be updated with the questions and answers so everyone can see them

Once we’ve picked out the best questions, we’ll approve all of the other questions and they will appear in the comments section of this post so other developers can help you out. We’re looking forward to your questions!

  1. Is there a way to interact with Dymo label printers from an iOS app? Sample app would be great. (from Steven Hepting)

Currently, the only way to print from an iOS device is using the DYMO Proxy Service that is installed with DLS. This service acts as the “middle-man” between your iOS device and your DYMO printers. For more information on how to use this proxy service, see the following blog posts: Please note that this service is still in BETA and has not been extensively tested outside of DYMO.

  1. Is the proxy service available for Mac? (from Matthew Dever)

The proxy service is a Windows only tool. Also note, the proxy tool is a beta release and there are no plans to move it out of beta.

Jul 172013

Hello everyone,

I wanted to talk a little bit today about the DYMO SDKs and compatibility with Windows 8. I’ll start with a quick answer: DYMO SDKs only work with Windows 8 desktop style applications. They do not work with Metro/Modern/RT style applications. Let’s dig a little deeper into why our SDKs do not work in Metro style applications and I will also describe a workaround for printing DYMO labels within a Metro application.

Metro Applications and COM

All of our SDKs use core DYMO assemblies that are installed with DYMO Label Software (DLS). For our older DYMO Label SDK, you add a reference to the DYMO COM objects directly in your application. For our “native” .NET DYMO Label Framework, we’ve created a wrapper assembly that calls our core DYMO assemblies through COM. Either way, COM is a necessary component for our SDKs to work.

Windows 8 Metro/Modern style applications operate under a different set of rules than desktop applications. One important rule being Metro applications are not allowed to access the registry. What does this mean for the DYMO SDKs? As discussed earlier, all Windows DYMO SDKs require COM to function and without registry access the loading of a COM object will fail. This means that, unfortunately, printing a label using the DYMO SDKs in a Metro application is not possible at this time. There is a workaround which requires a bit of work, but I will describe the basic process to get you started.


After installing DLS, any time a new DYMO printer is connected to your machine it registers as a standard Windows printer. This means that you can print to your DYMO printer from any application just like you would any other printer. For instance, you could type some text in a Microsoft Word document and print it to your DYMO printer. They key to getting it to print correctly on your label is to make sure the document size you are using in Word matches the label type you have in your DYMO printer.

Following the principles described above, you could create a printable document in your application, place anything you want on this document (text, images, etc.), and print this document to your DYMO printer. The creation of the document and anything on the document is entirely your application’s responsibility since you would not be using our SDKs. What your printable document is depends on what environment you are working in. One example would be an XPS document if writing a .NET WPF application. A great example for creating and printing a document within a Metro application can be found on Diederik Krols blog. Following Diederik’s tutorial and making sure that your document size matches your label size, printing to a DYMO printer from within a Metro application should be fairly straightforward, albeit not as easy as using a native SDK.


Over the past several months, we have received many questions regarding DYMO SDKs and Windows 8 support. We have taken note of this and are currently researching ways to improve our SDKs and provide support for as many platforms as possible. For the time being, we hope that the workaround described above will provide those of you writing Metro applications with a viable method of integrating DYMO printers into your applications.


Jun 172013

Hello everyone,

Today I wanted to talk a little bit about a common problem a lot of our SDK developers run into involving Internet Explorer’s Protected Mode. Protected Mode was introduced in IE 7 alongside Windows Vista and was designed to prevent malicious code from being executed in an IE process. Protected mode essentially forces the IE process to run with very restricted privileges, preventing any unwanted executables or code from being run. Any operation from loading an ActiveX control to writing to the registry could potentially be blocked by Protected Mode.

So, what does all this mean to a DYMO SDK developer? A lot of our developers load our SDK in their web applications by using ActiveX controls. As mentioned earlier, if IE is running in Protected Mode and a web application attempts to load an ActiveX control, this operation will be blocked. Luckily, Microsoft has provided a way to securely allow web apps to load ActiveX controls: Trusted Sites.

Any site that is marked as “trusted” will have more privileges than one that does not. To allow a site to load ActiveX controls, users must specifically add a site to the trusted zone. This ensures that the user is in full control of what is allowed to run in their browser. If you are using ActiveX controls and your users are having troubles running your DYMO SDK application, your first step should be to ensure your site has been added to the trusted zone. Below are a couple of links to information about Internet Explorer’s Protected Mode and also a walk through on how to add a site to the trusted zone.

Understanding Protected Mode

Adding a site to the trusted zone

Dec 262012

Hello everyone!

As promised, this is the second post in the FAQ series. Today, we will be getting a bit more technical and diving into some questions regarding SDK code. Let’s get started!

1. I am trying to create a label with several objects but this seems difficult to do using the SDK APIs. I feel like I am creating my label the wrong way. How should I be creating my label using the SDK?

Although it is possible to layout a label entirely using our APIs, we recommend that you first create your label using DLS and then load this label with our API. For most SDK applications this approach should work well as it will reduce the amount of code for creating the label as well as allow you to edit the data on the label based on any user inputs. For instance, let’s say your were making an application that would create name badges for a conference your company was hosting. You could create a label in DLS with two text fields: one for name and one for company. Then, as attendees arrived at your conference registration table, you could simply type in the name and company of the attendee and your application would update the data on the label using our APIs and print out the name badge. See the code samples below to learn how to load the label and update the label data using both the older SDK and newer Framework. For the purpose of these examples, assume your label was named “NameBadge.label” and your name and company text objects were named “NameTxt” and “CompanyTxt”, respectively.


DYMO Label Framework

 DymoAddInClass _dymoAddin = new DymoAddInClass();
 DymoLabelsClass _dymoLabel = new DymoLabelsClass();
 _dymoLabel.SetField("NameTxt", "John Smith");
 _dymoLabel.SetField("CompanyTxt", "Newell Rubbermaid");
 _dymoAddin.Print(1, false);
 var label = DYMO.Label.Framework.Label.Open("NameBadge.label");
 label.SetObjectText("NameTxt", "John Smith");
 label.SetObjectText("CompanyTxt", "Newell Rubbermaid");
 label.Print("DYMO LabelWriter 450 Turbo");

2. Every time I print to my Twin Turbo the label prints from the left tray. How can I print to the right tray?

Changing to the right (or second) tray is relatively simple in both the SDK and the Framework. However, it may be difficult to find this setting without knowing where to look. In the SDK, you simply specify a tray number (an integer) to indicate which tray to print to. You will use the Print2() method instead of Print(). In the Framework, there is an enum you use in conjunction with the LabelWriterPrintParams class. See the examples below.


DYMO Label Framework

 _dymoAddin.Print2(1, false, 1);

 The third parameter in the line above indicates 
 the tray number to use.
 LabelWriterPrintParams p = new LabelWriterPrintParams();
 p.RollSelection = RollSelection.Right;
 label.Print("DYMO LabelWriter 450 Turbo", p);

3. How can I create a tape (continuous) label using your SDK?

To create a continuous label, you must use the DYMO Label Framework. The older DYMO SDK does not support continuous labels. The layout mechanism of a continuous label is quite different than that of a die-cut. A continuous label uses a cell layout system instead of the fixed location system of a die-cut label. For example, if you were using a die-cut label and wanted to place three text objects side-by-side-by-side, you would manually set the location (x,y coordinates) of the three objects on the label.


However, for a continuous label, you would need to add three subcells to the root cell of the label and then insert each of your text objects into one of the cells.


Continuous labels are the simplest way to create a label on the fly. Continuous labels automatically size to their content (unless otherwise specified) and provide an organized layout system. Below is some sample code illustrating how to create the label displayed above using the DYMO Label Framework and continuous labels.

            ContinuousLabel label = new ContinuousLabel("Tape9mm", PaperOrientation.Landscape, ContinuousLabelLengthMode.Auto, 0);
            label.RootCell.Subcells.Add(new ContinuousLabelCell());
            label.RootCell.Subcells.Add(new ContinuousLabelCell());
            label.RootCell.Subcells.Add(new ContinuousLabelCell());

            label.RootCell.Subcells[0].LabelObject = new TextObject("Txt0");
            label.RootCell.Subcells[1].LabelObject = new TextObject("Txt1");
            label.RootCell.Subcells[2].LabelObject = new TextObject("Txt2");

            label.SetObjectText("Txt0", "This");
            label.SetObjectText("Txt1", "is a");
            label.SetObjectText("Txt2", "test.");

4. I would like my application to interface with a DYMO scale. Is there a DYMO scales SDK?

We do not provide an SDK for DYMO scales. Our scales conform to the HID standard and can be accessed this way. The HID standard for scales is documented in section 4 of this document. Jan Axelson has a useful page on HID development with plenty of examples. Nicholas Piasecki and Mike O’Brien also provide some useful resources on HID scale development.

That wraps up this second FAQ post. Hopefully all of you developers found these posts useful and continue to use our SDK and our printers.  I hope everyone enjoys the rest of this holiday season and has a happy New Year!

Dec 172012

Hello everyone! It’s been a while since we have had a new post here on the blog (other than occasional Firefox update post). We have been busy working on many new and exciting things that we are looking forward to sharing with you in the coming year! This past year has also seen a number of new products from DYMO including:

  1. Our first touch screen printer, the LabelManager 500TS
  2. A new handheld, the LabelManager 280
  3. An update to DLS to support our new printers (you can download it from here)

We thought we would wrap up the year with a post answering some of the most frequent SDK questions we receive. This will be a 2 part series with a second post coming later answering more of your FAQs. This first post will answer some of the more high level questions about getting your DYMO SDK app up and running. The second post will be a bit more technical. Without further ado, here we go!

1. I have downloaded and installed the DYMO SDK from this web page. However, I am unable to find or load the DYMO COM type library in my project. What am I doing wrong?

In fact, you really haven’t done anything wrong. There has just been a bit of miscommunication. The DYMO SDK installer (which can be found here) only installs samples, no binaries. To get the DYMO binaries, all you need to do is download and install the latest version of DLS (which can always be found here). Once DLS is installed, you should be able to find the type libraries as described in this post.

2. Is there a difference between the DYMO SDK and the DYMO Label Framework?

Yes. The DYMO SDK is our older API that is built using COM. You add references to our COM type libraries in your project and you’re off. The DYMO Label Framework is our newer API that we encourage all developers to use. The DYMO Label Framework is “native” to .NET, being written mostly in C#. You add references to our binaries in your project just as you would any 3rd party .NET library. The DYMO Label Framework also provides a greater feature set than the older DYMO SDK, which leads us to our next question.

3. I have downloaded and installed DLS and added a reference to the DYMO COM type library in my project. However, I cannot print to my tape printer using the SDK. What is going on?

The older DYMO SDK does not support printing to tape printers (i.e. the LabelManager series). It only supports printing to die-cut printers (the LabelWriter series). In order to print to a tape printer, you will have to switch to the newer DYMO Label Framework which supports both tape and die-cut printers. In fact, there are several other advantages to switching to the newer DYMO Label Framework. See the chart below.



DYMO Label Framework

.NET & COM support
 MC900072629[1]  MC900072629[1]
Die-cut printers
 MC900072629[1]  MC900072629[1]
Tape printers  MC900072629[1]
JavaScript API  MC900072629[1]
QR Code  MC900072629[1]
Web SDK (Beta)

That’s all for now. Keep checking back for the second part of this FAQ series where we will dive into the code and answer some questions that are a bit more technical. Happy holidays everyone!

Oct 122011

Suppose you are a developer and you are integrating a DYMO LabelWriter or LabelManager printer into your application by using DYMO Label Framework or older DYMO Label SDK API. Usually the integration is quite simple and "just works", and you can print a first label in a matter of minutes. Sometimes however, something might went wrong and don’t have the expected result. Or everything is fine on your machine, but the application does not work on the customer’s machine. What to do? Here are some tips could help in troubleshooting and investigating the problem.

Check DYMO Label software version

In most common usage scenarios, the DYMO Label software is required to be installed on the same machine where your application is running (for more information, see this and this). Usually we recommend to install the latest available version, unless there are knowing problems with a particular release. The latest version is available from DYMO site, here is the link.

Do a test print from DYMO Label software

Try printing a label from the DYMO Label software. DYMO Label software and the SDK libraries share a lot of underling code, so, if you can’t print by using the SDK, there is a big chance there will be problems with the DYMO Label as well. So, if you can’t print from DYMO Label or there are other problems running it, then contact DYMO tech support. Usually you will be asked to provide installation/configuration information, this can be obtaining by running LWSupport utility from the “[Program Files]DYMODYMO Label SoftwareSupport” folder.

Restart (open/close) web browser

If you are using DYMO Label Framework JavaScript library and just installed DYMO Label software, you might need to restart the browser to have the Framework plugins loaded. Also, you might need to restart the browser if you have added a new DYMO printer.

Verify browser compatibility and the Framework installation status

If you are using DYMO Label Framework JavaScript library, open and click on “Check” button. The installation information will be displayed.

Collect trace/log information

DYMO libraries can generate log/trace information is not visible to end-user. To grab it use DebugView on Windows and standard Console application on Mac. On Windows: start DebugView, start your application, print a label, collect all messages displayed in DebugView. On Mac: open Console application, clear current messages, start your application, print a label, collect all messages displayed. Send all the collected messages to the e-mail address below.

Contact SDK support line

If you have any questions regarding the SDK, e-mail us at [sdkreply at newellco  com]. Please note, this is SDK-only support e-mail. For questions regarding DYMO Label software itself, please contact DYMO tech support

Oct 052011

An experimental support for QR code and PDF417 barcodes has been added in DYMO Label 8.3. You will have to edit a label file manually, because there is no UI support yet. Just create a label in DYMO Label, save it into a file, open a file in your preferred xml editor, locate barcode type element (XPath is like /DieCutLabel/ObjectInfo/BarcodeObject/Type); enter “QRCode” or “Pdf417 ” for the Type inner text. Now you can load this label using DYMO Label Framework JavaScript Library and set the barcode content as for any other barcode type, e.g. by using label.setObjectText() or record.setText(). It will work with other APIs we provide as well.

Here is a sample label contains both barcode types,


<!--?xml version="1.0" encoding="utf-8"?>
<DieCutLabel Version="8.0" Units="twips">
    <PaperName>30252 Address</PaperName>
        <RoundRectangle X="0" Y="0" Width="1581" Height="5040" Rx="270" Ry="270" />
            <ForeColor Alpha="255" Red="0" Green="0" Blue="0" />
            <BackColor Alpha="0" Red="255" Green="255" Blue="255" />
            <TextFont Family="Arial" Size="8" Bold="False" Italic="False" Underline="False" Strikeout="False" />
            <CheckSumFont Family="Arial" Size="8" Bold="False" Italic="False" Underline="False" Strikeout="False" />
            <QuietZonesPadding Left="0" Top="0" Right="0" Bottom="0" />
        <Bounds X="331" Y="57.9999999999999" Width="1434.3307302029" Height="1435" />
            <ForeColor Alpha="255" Red="0" Green="0" Blue="0" />
            <BackColor Alpha="0" Red="255" Green="255" Blue="255" />
            <TextFont Family="Arial" Size="8" Bold="False" Italic="False" Underline="False" Strikeout="False" />
            <CheckSumFont Family="Arial" Size="8" Bold="False" Italic="False" Underline="False" Strikeout="False" />
            <QuietZonesPadding Left="0" Top="0" Right="0" Bottom="0" />
        <Bounds X="2086" Y="57.9999999999999" Width="2867" Height="1435" />
Aug 202011

Recently the site we use to host most of our SDK samples, documentation, installers, etc was in a coma for almost a day. Fortunately,  it survived. Unfortunately, this caused a lot of trouble for our users, for which we are sorry.

Some lessons learned from this unpleasant expirence:

  1. Don’t host a front-end and a back-end on the same site. By front-end I mean a standard web-site, by back-end – a file storage, developer’s documentation, etc. Some day a manager who knows nothing about the back-end will come and decide the web-site should rest in peace. IT will break everything in a flash, but its not that easy to restore.
  2. Some developers link directly to js library from Though we will try not do make the same mistake again, the site is not really designed to be used in mission critical applications. So, it would be a good idea to host the library on your own sites, where you have more control.
  3. Some developers link to the “latest” version of the library from their pages. This latest file is not intended to be used on production servers. The file serves two main purposes. First, at DYMO we link to it from our samples; because we have a lot of them, for us it would be painful to update all of the samples with any new release of the library. Second, it might be linked from a page on a staging server or a test machine; so, a new, latest, version can be easily tested with your application. On production servers, it is better to link to a specific version of the library, that your application was tested with. At the time of writing the latest version is 1.2.