Sep 302015

Hello everyone,

A lot of our SDK users are running into a particular issue printing barcodes where they will be clipped or not printed at all. The issue is actually being caused by a bug in the .NET Framework (v4.0 and newer), specifically in XPS printing. The trigger for the issue is when our printers go into “Barcode and graphics” mode. Unless manually overridden, the DYMO SDK will switch the printer to “Barcode and graphics” mode whenever a barcode or image object is present on the label. When in this special mode, the resolution of the printer changes from 300 x 300 DPI to 300 x 600 DPI. This “non-square” resolution is not handled correctly by XPS and causes the clipping issues.

Below is an example of this issue. The label on top is OK while the label on the bottom is printed with the issue.


What you may notice is the label with the issue stops printing at a distance across the label that is equal to the width of the label. This is the crux of the XPS bug and as you can see, also affects other label object types as well.


Now that we understand the issue a little better, what can we do about it? Let me start by saying that we have made Microsoft aware of this issue. Since there are no guarantees they will fix the problem, we are currently working on a solution that will be pushed out in a future update of DYMO Label Software. In the meantime, you have a few choices for working around the issue:

  • Design your label in portrait orientation. For most label types, the issue will not arise if the label is printed in portrait orientation. By using the object rotation feature in DLS, you can easily design a label in portrait orientation that will look identical to one designed in landscape orientation.
  • Compile your SDK applications against .NET 3.5. As mentioned earlier, the issue is with .NET Framework versions 4.0 and newer. Current versions of DLS are compiled against .NET 3.5 so you will not see this issue when printing from DLS. However, if you are compiling your SDK application against newer versions of .NET, when your application runs, the newer version of the framework will be loaded. Even though the DYMO SDK binaries are compiled against 3.5, .NET backwards compatibility will kick in and the newer version will be used instead. So, to take this approach, you will need to compile your SDK application against .NET 3.5.
  • Force the print job into “Text” mode. In the DYMO Framework, you can override the print quality setting using the ILabel.Print(IPrinter, IPrintParams) API. An example of how to override this setting can be seen below (the parameter used to change the print quality is marked in bold):

    LabelWriterPrintParams prms = new LabelWriterPrintParams(1, "print job 1", FlowDirection.LeftToRight, RollSelection.Auto, LabelWriterPrintQuality.Text);
    _label.Print(printer, prms);

Thanks for bearing with us on this issue. Rest assured we are working hard to get the fix out. In the meantime, we hope this blog post will help you get your labels printing correctly.

Mar 242014

Hello everyone!

A new version of our JavaScript library is now available. This version fixes several printing issues specific to Internet Explorer 11.

The new DYMO Label Framework JavaScript Library 1.2.6 is available here:

The latest has been updated to version 1.2.6 as well:

Oct 312013

Hello again,

We at DYMO our very appreciative of our SDK community. Over the years, we’ve seen some very interesting and cool applications that integrate with DYMO printers. We thought it would be fun to showcase some of these applications here on our developer blog! If you’ve been involved with the creation of a DYMO SDK application and would like to have it shown here on the blog, just comment on this post with some information about your application (description, pictures, website link, etc.). We’ll sort through all of the responses and pick some of our favorites and showcase them on the blog. We’ll keep all of the responses private and contact those that we want to showcase directly before posting anything to the blog. We look forward to seeing what everyone has created!

Sep 302013

A quick post here to help out some of our developers that are integrating CardScan into their applications. We receive quite a few CardScan SDK questions and usually we have to forward them over to the correct support group. This is due to a miscommunication on our part, and we wanted to get the correct CardScan SDK support information out there. All CardScan SDK questions should be directed to the email and phone numbers below. We apologize for any confusion.

Email: [email protected]

Phone: 800-942-6739×1   M-F, 8:30am-5:30pm EST

Dec 232011

Happy holidays to all DYMO users and developers! Thank you for being with DYMO, for all the questions, comments, and feedback. It’s invaluable!

2011 was quite a year, with a lot of new releases and new features.

It started with releasing of DYMO Label software 8.3 that added full support for new DYMO Label Framework API and JavaScript Library.

Next, we expanded the presence in the web and mobile dimensions by releasing DYMO Label Web SDK, DYMO Label Mobile SDK for iOS, and DYMO Label Mobile SDK for Android. Although SDKs are still officially in the beta stage, we know they were successfully used, e.g. MailChimp used it on iPad for visitor management, and Google itself used it on Android during developers conferences.

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.

To support Mac OS X 10.7 Lion, we released DYMO Label software 8.3.1 and did some internal fixes to JavaScript library.

Finally, DYMO Label SDK for Windows was released with updated samples and documentation.

On the sad note, after dozen years with DYMO, I am leaving the company and this is my last post.

Anyway, Happy Holidays! Happy New Year! Let new year be better, brighter, more peaceful than 2011. May the Force be with you. Live long and prosper. Bye.

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.
Aug 192011

We host a lot of samples and documentation on Unfortunately, the site is down at the moment and most of the samples are not accessible.   We are working on resolving the issue. Thanks for understanding.

Update: The latest version of DYMO Label Framework JavaScript library can be found here.

Update 2: the site is running now.

Mar 212011

We receive a substantial number of questions regarding what to install on a client machine to be able to run an application that uses the DYMO SDK. Should it be DYMO Label software,  DYMO Label SDK, or both?

The answer is — only DYMO Label software has to be installed on a client machine to enable/support DYMO SDK functionality. The DYMO Label software installer includes all necessary binaries needed to run an SDK application. It installs printer drivers, installs libraries and services, and registers the COM components. The latest production version of DYMO Label software installer can always be found on Beta versions with extended SDK functionality are available on this blog.

By contrast, the DYMO Label SDK should be installed on a developer machine only. In fact, it is not required, because the  DYMO Label SDK installer installs documentation and samples only. If you are familiar with the SDK API you might not need it at all. The latest version of the SDK installer is available on

Jan 132011

We are proud to announce the release of DYMO Label software version 8.3.

Starting with this release, the new DYMO Label Framework and DYMO Label Framework Java Script library are officially supported.

DYMO Label installers are available from the links below. SDK samples and documentation will be updated in coming weeks.

Download Links

Windows DYMO Label v.8 Installer

Mac DYMO Label v.8 Installer

What’s New

DYMO Label Framework JavaScript Library

To simplify using DYMO Label SDK from web-based application we created a JavaScript library that abstracts browser and platform details for accessing DLS SDK from JavaScript. Now you can use the same JavaScript code to add printing support for any browser the SDK supports. Currently supported browsers are:

  • On Windows: Internet Explorer 6+, Firefox 2+, Chrome 4, Opera 10, Safari
  • On Mac: Safari 4+, Firefox, Chrome, Opera

Major Features

  • Simple cross-browser and cross-platform API
  • Ability to load and print a label from: a web server, the local file system, or construct on the fly in JavaScript
  • Ability to load images from the server or from local file system
  • Ability to print multiple labels at once


64-bit Support

Now you can use the SDK from 64-bit processes, e.g. Internet Explorer 64-bit. The only thing to do is to recompile your application to be 64-bit, no need to change any code.

New DYMO Label Framework API

Starting this introduces a new API – the DYMO Label Framework. It provides a simpler streamlined interface for printing labels.

Major Features

  • Support for 32-bit and 64-bit applications.
  • Support for DYMO LabelManager Tape printers. Now you can use the same simple API to print on Tape printers as for printing on LabelWriter printers. All you need to do is to design a Tape label in DLS, load it in your application and print.
  • Native .NET support. The Framework provides native .NET support. There is no need to use COM-Interop anymore. Features available in .NET such as indexed properties, enumerators, etc are used to provide an API that is easier to use.
  • COM support. Microsoft COM is supported as well, similar to current SDK.
  • Consolidated High and Low Level API. The Framework combines the current high-level and low-level APIs into a single API. Now there is no need to switch between APIs if you need some advanced functionality not available in high-level API.
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.