Dec 122017
 

Hello everyone,

Chrome recently released an update to Chrome (version 63) that includes experimental support for TLS 1.3. Unfortunately, this is causing problems with our client-side web service that powers the JavaScript SDK. We are currently looking into this issue but in the meantime, there is a workaround available. The following steps need to be performed on affected versions of Chrome:

  1. In the Chrome URL bar, enter chrome://flags and hit Enter
    chrome_flags_url
  2. Once on the chrome://flags page, find the setting for TLS 1.3
    chroms_tls13
  3. Change this setting to Disabled
    chrome_tls13_disable
  4. Relaunch Chrome
    chrome_relaunch

Once Chrome restarts, you should no longer receive the ERR_SSL_VERSION_INTERFERENCE error. We will update this post as we continue to research this issue.

May 042017
 

It has come to our attention that Google Chrome is flagging calls to the DYMO Web Service as “not secure.”  This has been causing many of our users to have issues when printing through Chrome.

We have found the issue and have an internal fix undergoing QA testing at this very moment.  We estimate the fix will be released within 2 to 3 weeks. We apologize for the inconvenience at hope this will be resolved soon.

In the meantime, please consider several temporary fixes that have been identified within the below blog post:

The new DLS 8.6.1 release is now available!

Nov 092016
 

Hi Everyone,

Our blog had some login and posting problems for an extended period of time due to unforeseen technical difficulties. As a result, we were unable to immediately respond to many inquiries over the past few weeks.

The problem has been resolved as of today, so any inquiries that were posted within the last month or so will now be addressed ASAP.

Thank you for your understanding!

Team DYMO

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.

IMG1

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.

IMG2

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: http://labelwriter.com/software/dls/sdk/js/DYMO.Label.Framework.1.2.6.js

The latest has been updated to version 1.2.6 as well: http://labelwriter.com/software/dls/sdk/js/DYMO.Label.Framework.latest.js

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: sales@cardscan.com

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