May 292018
 

Hi everyone,

Today, we are releasing an updated version of our JS SDK and DLS to address some security and TLS issues. These updates are now live on dymo.com and labelwriter.com. You will find download links below. Please note that the latest version of DLS requires the latest version of JS SDK. If you plan to update your users’ DLS version then you will also need to update the JS SDK version used in your application.

DYMO Label Framework JS SDK – http://labelwriter.com/software/dls/sdk/js/DYMO.Label.Framework.3.0.js

DLS Windows 8.7.2 – http://download.dymo.com/dymo/Software/Win/DLS8Setup.8.7.2.exe

DLS Mac 8.7.2 – http://download.dymo.com/dymo/Software/Mac/DLS8Setup.8.7.2.dmg

May 092018
 

We wanted to take time to highlight some changes that will be coming to the SDK web service in the next update of DLS. The changes are centered around reducing potential security risks as well as improving the overall end-user experience.

  • Behavior change for disconnected users

    Currently, when the JavaScript SDK tries to discover the DYMO SDK web service instance running on the machine, it does so by scanning all ports within a range. The first port that responds is the one that is used. If the JavaScript SDK connects to a web service instance the belongs to a disconnected user, printing will fail.

    In the upcoming version of DLS, the web service for each user will suspend itself if the user disconnects (either due to fast-user switching or temporary RDP session disconnect on a remote machine). Once the user becomes active again, the service will resume. This will ensure that only one instance of the web service is active at any given time (NOTE: for Windows Terminal Server multiple users can be active simultaneously so multiple web service instances can be running)  and will prevent any issues dues to multiple web service instances.

    The DYMO SDK web service scans a 10 port range in order to find an available port to run on. In the event of all 10 ports being taken (meaning there are 10 active users logged onto a machine), any new users that log on will not have their own web service instance but instead use one of the existing 10 instances. For most common usage scenarios this will not be a problem. However, if the JavaScript SDK connects to another user’s instance (due to being the first to respond to the port scanning), shared printers for the other user will be visible through the SDK but shared printers for the current user will not.

  • Random certificate generation

    Root and exchange certificates will be generated randomly using strong cryptographic keys during DLS installation and discarded immediately after installation. This ensures the certificates are unique for every DLS installation and adds an extra layer of security to the DYMO SDK web service.

  • Change in web service URI

    The DYMO SDK web service will be changed to use 0.0.1 instead of localhost as its URI to avoid host name spoofing. This means that the existing JavaScript SDK will not work with the new web service installed with DLS. An upgrade to the new version of the JavaScript SDK will be required if a user updates their DLS install. However, the new version of the JavaScript SDK will be backwards compatible with older versions of DLS.

  • Firefox changes

    The new web service for DLS Windows does not install a root certificate into Firefox’s local keychain. Instead, it enables Firefox’s built-in feature which allows Firefox to user OS certificates. This flag is set on DLS installation and removed on DLS uninstallation.

Apr 242018
 

UPDATE

A new version of DLS is available that resolves this issue. This will need to be installed on any client machine experiencing the slow printing issue. You can download it here:

 http://download.dymo.com/dymo/Software/Win/DLS8Setup.8.7.1.exe

UPDATE 2

The above version of DLS is now live on DYMO.com for all regions.

http://www.dymo.com/en-US/online-support/dymo-user-guides

Since 4/23/2018 all users of the windows version of our SDK have been experiencing a 10-15 second slowdown. The issue can also cause performance issues when opening label files in DLS.  This appears to be caused by our code attempting to contact 128.30.52.100 (http://www.w3.org/1998/XMLSchema)  in order to validate each label before printing.

We have identified a fix for this issue and we are currently expediting a test cycle so we can release a patch as soon as possible.

Until the actual fix goes out, users can alleviate this slowdown by preventing this call.  We have seen success with two methods thus far.

  1. Prevent connections to 128.30.52.100 (http://www.w3.org/1998/XMLSchema)
  2. Use the windows defender firewall to prevent DYMO.DLS.Printing.Host.exe from making outbound connections.

 

We apologize for the inconvenience, and will update this post as soon as the situation has been resolved.

-Regards,

DYMO Team

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.