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.

Requirements

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

Tracing

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

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.

Thanks dev team, appreciate all your hard work! HTTPS is essential for us as we are working with personal counselling information that legally we must ensure is kept confidential. Look forward to seeing this supported, hopefully we can test this very soon.

I can tell you that legally, you should be just fine. Fire up wireshark & watch what happens with communicating with the DYMO service; you won’t see any traffic. Either way this issue should be fixed, but I hope this information helps to put you at ease.

Hi Al, The requirements are client based. The Service resides on the client and interacts with the any available DYMO printers on the client machine. The older architecture that used the native plugins also required DLS to be installed. For release, we are making the service part of the DLS installer and we are going to investigate adding the patch to the installer as well.

Thanks for the update. It works for me on Windows using Chrome over http. I wish it supported TLS so I didn’t get a mixed content error in Chrome. I am subscribed to your feed, so I will see if https is ever supported. Currently, I can allow mixed content in Chrome once, but when I close and re-open the same tab, I receive the same mixed-content error. This results in a user experience for my use case that makes the Dymo label framework an unusable javascript library until it supports TLS. I would be happy to answer any questions Dymo has regarding my use case. You now have my email address. Thanks for all you do.

To call it a beta when you don’t support HTTPS is to misuse the term “beta”. If you’re still adding features this is an alpha release at best. There is already a simple solution to the HTTPS problem that’s being employed by other hardware vendors supporting in-browser extensions. (Notably Topaz Signature Pads)

Install a trusted root certificate into the windows root store & Firefox’s root store, create a certificate (*without* signing privileges) for a ficticious subdomain of dymo.com (e.g. printhere.dymo.com) and make a certificate for the domain signed by the trusted root. Then modify the hosts file so that that domain redirects to localhost. This provides HTTPS connections to services on localhost.

I accomplished this in a rigged version of a chrome compatible Dymo service I made myself. It’s simple, and I’m sure more than half of us need this feature. We can’t constantly bother our users with security warnings, particularly in our case when we’re handling medical data.

Hi Austin, We released this beta early due to the demand from our customers. We wanted to get something into everyone’s hands to start testing our solution in their environments. We were aware of the limitation around HTTPS, this is why we highlighted it in the post and getting HTTPS to work fully is our top priority. Thank you for the information about your solution.

Security is not a concern here. Since it talks to localhost only, all communication is done locally – data is sent from one app to another via OS kernel directly, so it never goes on the wire. Though you’re right about annoying messages, it should be fixed.

As for fiddling with hosts file… many proactive protection software will treat this as a threat and block it.
What if there’s no Firefox at the time of installation but then I install it. Shold they make service to scan for browsers all the time?
Anyway, I don’t think fake certificates is a good solution.

If you install firefox after you install the framework, you would need to again install the plugin/service, just like you would with any other add-in.

Strictly speaking “fake” certificates are not required. This would also work if you got a cert for somethingorother.dymo.com signed by a trusted CA, redirected via hosts, and used that “real” cert. This removes the step of installing a trusted root into windows/firefox’s certificate store.

The issue there though, is I don’t think the CA would be too happy about you distributing the private key for a cert they signed to thousands of people, even if it’s never used for real web communications, and if they revoked the cert it could suddenly kill the app for everyone using HTTPS.

Additionally, a “real” CA will never sign a certificate for localhost, as it violates baseline requirements. As a result, this is really the only way to make an HTTPS connection to 127.0.0.1.

Again, this method is currently being used several manufacturers who used to rely on NPAPI/Activex.

As far as we are aware, there should be no barcode issues when printing from DLS, no matter which versions of Windows you are running or which version of .NET you have installed. However, if you have written a custom Framework/SDK application and compiled against anything other than .NET 3.5, you may run into issues printing barcodes. Are you seeing issues with DLS or with an SDK application?

The issues are from an SDK application that our team developed. They only showed up when I installed VS2015. Do you plan on supporting further .NET frameworks? .NET 3.5 is about 7 years old and many custom applications have moved on to later versions of the framework. Even moving the printing logic to a separate dll that targets .NET 3.5 doesn’t fix the issue, but you are correct if the whole application targets .NET 3.5 the labels print correctly. Unfortunately there is no way to target our application to .NET 3.5 as we use many features in later framework versions.

I have an example application I can send you if it would help track down the issue.

The bug is actually in the .NET Framework and is caused by the way Microsoft handles printers with “non-square” resolutions (ex.600×300). When barcodes are present on a label, we print at this higher resolution instead of the normal 300×300 to help with barcode quality/scanning. We had logged an issue with Microsoft and they claim to have fixed the problem in .NET 4.6, although our preliminary testing does not seem to indicate so. We are continuing to look into this issue and trying to find workarounds. One solution that works in some scenarios is printing labels in “portrait” orientation. Though not ideal since you would need to redesign you label, this may work in your case.

Hi Phong, We have not experienced any issues installing the patch, are you running the patch as an administrator? As to the init is not a function error, are you using the version 2.0 of the DYMO Label JavaScript library? You might want to double check your script tag. Also, are you using it with the appropriate callback as it is detailed in the post?

I’ve got it working on our other Windows 8.1 computer. I just don’t know why that patch KB2954953 can’t be installed on my computer. It doesn’t have the option to run as administrator when I right mouse click on it.

This solution is browser agnostic. I’ll need more information to diagnose this issue. Have you tried the patch listed in the original post? Are you linking the appropriate version of the JavaScript Library? Can you check the Developer Console and look at the network traffic to see if the web page is hitting the web service? Have you added the init method to your JavaScript?

Thanks for your work on this fix. It’s such a bummer that Chrome is pulling the plug on such a long-standing API. I know it’s a bit dated but… it works! Too bad.

I’m working on updating my app. In the meantime, it struck me that it could be nice to have some error handling. For example, if the user isn’t running the webservice (or, if the client can’t find the webservice), we could display an error saying what’s wrong. Maybe the handler could be used for other things, like unsupported platforms (eg, calling “init” on a Mac).

Hi Robert, I think the bigger bummer was that Chrome didn’t provide a suitable replacement for NPAPI but on the plus side, we’ve been able to create a solution that is independent of the browser.

There are trace messages that get added to the developer console in the browser. It is pretty easy to tell if the script is connecting to the web service or not, you’ll see http requests to our web service. We do not display an error because we would like to fall back to using plugins. This is an attempt to avoid breaking peoples scripts that either have a slow roll out or not roll out of the service.

We could look at adding a parameter that prevents fallback and returns an error if it can not connect to the web service. Would this be useful to you?

One quick tip (that you might want to add to the instructions above): the Web Service kept failing to install on my computer. I tried everything and was about to give up. Suddenly I remembered my antivirus program was running! (Avast Free) I disabled it temporarily and the Web Service installed without a hassle.

So you might have to temporarily disable your antivirus software in order to install the Web Service.

We are still working out the 100% support solution for https that will not need any user interaction. At this point, the earliest we’ll be able to deliver a potential solution is mid to late next week. The current solution will work for https but may need customer interaction depending on the browser. We apologize for this inconvenience, but it is our number 1 priority. The Mac solution is still in development.

Go a LabelWriter 450 and interested in adding badge printing feature to our application. Searched the web and perused dymo blog but can’t find a home page with the right bits to download, samples, api doc, etc.

Hi Forrest, I’m sorry that you are having issues. Can you give more details on what you have installed so far? DLS should be installed first before the web service. Are you running as an administrator on the machine?

We’re shipping other-brand-printers to our Mac users as a short-term fix for Dymo’s late drivers for Mac, and work-around for non-https support for Chrome telling our clients to install beta version, hopefully we don’t hit any bugs as this is beyond last-minute.

I’m currently having some trouble with the DLS Web Service windows service. I’ve looked at the windows services currently configured.
The DLS Web Service is exists and is set to start automatically. However once i look at the services it is not running, causing the framework not being able to find the printers. I have solved this problem by re-adding the service using this:

Hi Leroy, We would need more information on your environment. What is the OS that you are installing on? What version of DLS do you have installed on this machine? Are there any errors showing up in the Event Viewer that pertain to the Service when it failed to start?

Will this work on Chrome OS? I would like to replace a laptop whose only function is to print labels from the web to a DYMO printer. I would love to save a few hundred dollars by going with a Chromebook, but I don’t know if I can install the DYMO software and have it work. Just wondering if anyone has tried this before. Thanks.

We have windows 8.1 computer which returns 400 on post request for print, while it returns list of printers correctly
Tried to Install Patch, but it failed: http://i.imgur.com/Rzc0Sfu.png
Any suggestions?

It would be great if dymo had a test page you could check that driver / local requests is working & test print.

Hi Halldor, It has been our experience that the patch is required to get the Web Services to work on windows 8+. We have not had any problems installing the patch internally. I can think of some basic troubleshooting steps like making sure that Antivirus is turned off and that you are running as administrator but beyond that you may need to contact Microsoft for support on their patch. As to the test pages, that is a good idea, we’ve been working hard on getting the new version of the JavaScript library working that we did not provide any test pages. I will have the team look into changing some of our existing examples to use the new version of the JavaScript library.

I’ve had the client update all updates, disable anti-virus and disable firewall as test, and still “MicrosoftFixit20131” fails. We called Microsoft and they weren’t much helpful, other than trying to charge a arm/leg for support time. I’m thinking It depends on a library which this computer might not have had installed by default? Question is what dependence it has.

If anyone have any ideas as to why the Patch might fail on Windows 8.1 other than up2date, firewall and antivirus it would be very helpful!

Language correction, “A new version of the DYMO Label Software 8.5.2 will become available.”, this is for Windows I’m assuming as for Mac there is already v8.5.2 released but this does not contain support for beta 2.0 driver. (at least it don’t work for me, just doublechecked.)

Have any of you thought about disabling chrome updates maybe for a month or two until there’s a more stable solution (I know this is not recommended etc. but at this point it doesn’t sound like a bad option to me). After a quick look it looks like there are a few ways to disable auto-updates but seems that it doesn’t work in the latest versions. Have you tried to do this?

45 has been released. If you haven’t updated it yet, I can confirm that renaming the “C:\Program Files\Google\Update” folder will hold Chrome update. As many of you I need HTTPS and I can’t rely on a last minute beta version as label printing is critical for the business

BTW, I think I found one difference in behavior with the 2.0 beta and the previous release.

On an environment where the plugin is not supported, the “checkEnvironment” function will now return a result object where “isFrameworkInstalled” is true.

To replicate:

– Open Firefox
– Don’t allow Firefox to run “DYMO Label” plugin
– Open a page with “1.2.6” and call “dymo.label.framework.checkEnvironment()”. You’ll either get an error or an object with “isFrameworkInstalled: false”
– Open a page with “2.0-beta” and call “dymo.label.framework.checkEnvironment()”. You’ll get an object with “isFrameworkInstalled: true” (I also see “isWebServicePresent: true”, even though I’m using OSX)

I _do_ have the Dymo framework installed so this might be a feature, not a bug :) I just thought I’d report it, in case it was useful to you!

This has really been an issue for us. I don’t understand how it comes down to a beta and no https when there was so much lead time. We use Dymos in our POS installs, but have had to buy and over-night sub-standard printers to many of our customers so we don’t loose them, they are not tech savvy enough to even find the Chrome “Update” folder and rename it… I hate to complain and not contribute but this has been bad!

In fact, it should work in Chrome if your page uses HTTPS (at least it worked for me). I guess it’s only Firefox affected.
The fact that JS code sends HTTP (not HTTPS) requests to localhost shouldn’t be a security concern – see Austin Maier’s and my posts above.
I hope HTTPS update is on the way.

HTTPS do not work out of the box with Chrome with Dymo Beta
You need to click on gray shield, and get popup this page is trying to load scripts from unauthenticated sources. Then click “Load Unsafe Scripts”, the page reloads and you need to do the request again.
The session with allowing unsafe script’s is only temporarily for the Browser Tab’s session.

I’ve checked all binaries from the package in DependencyWalker and there are no static dependecies except .NET 3.5 Framework.
But there are two “Interop.*.dll” file which means it has some runtime(COM) dependencies, so I guess that’s why DLS should be installed prior to the service.

According to KB2954953 description, it fixes a bug that prevents system service from accessing printing subsystem. I think it’s about 32-bit service on a 64-bit host(not sure). I used it on my 64-bit machine, didn’t try on 32-bit machine.

Hi Daniel, The underlying code has remained mostly unchanged, we are working mostly on the communication portion between the browser and the installed software. Thank you for letting us know, we’ll investigate this issue.

Thanks for the beta, but are you guys at DYMO aware that Chrome 45 was released, thus removing all support for NPAPI? The time has come and there is not a viable alternative yet, especially considering this method does not support HTTPS and the fact that it’s still in beta stages.

The “DYMO Web Service Beta Installer” service does not start in Windows 10.

I get this error in EventViewer:

An unhandled exception ('System.Reflection.TargetInvocationException') occurred in DYMO.DLS.Printing.Host.exe [24364]. Just-In-Time debugging this exception failed with the following error: The operation attempted is not supported. Check the documentation index for 'Just-in-time debugging, errors' for more information.
21400080

Do you have the latest version of DYMO Label Software installed on the machine? Can you give us more details on your environment? We have tested on several different Windows 10 configurations and have not had an issue.

Hi there,
are you any closed to releasing the update and making the software update available on the “Help\Check For Updates” menu item?
Our customers are not savvy enough to be pointed to a download link for a beta version. Hopefully they will just about be able to click the “check for updates” option if I send them an email with pictures and instructions in!
Their browsers have now all updated to the new Chrome which no longer supports NPAPI (full stop), and typically they all use Chrome instead of IE….
Cheers

We had run into some issues with getting HTTPS to work smoothly, those issues are solved and the next version is in testing. If nothing major comes up, we should have a new version of the Beta early next week.

Hi Caroline, We are trying to get it ready as soon as possible for release. There are issues that we discovered during testing that need to be fixed before we can release. We apologize for this delay, it was our best intention to have it released by now.

About 2/3 of our customers use Chrome, and 3/4 of them use Windows. We were really hoping to see the Windows version of the update come out before the reports of Dymo in Chrome no longer working started rolling in. An updated timeline on both the Windows and OSX version would be appreciated.

Hi Halldor, we’ve seen several reports that printers shared over the network are not being seen by the new service. We have tried to reproduce and have been unsuccessful. Can you more details of your set up so that we can more accurately reproduce the issue?

I commented above. I can reproduce this every time in the following way:

Two fresh installs of Windows 7
Install Dymo software as recommended in this post.
Install a Dymo printer on Computer 1 (local USB connection) with default name
Share the printer from computer 1 (share name is Receiving DYMO if that matters)
On computer 2, add a network printer and choose the printer shared from computer 1.
The Dymo software on computer 2 WILL print labels successfully to printer 1 using the actualy DYMO software.
Open up an run something in chrome that calls dymo.label.framework.getPrinters()
On computer 1, this will show the printer
On computer 2, this will return an empty list

Feature request for javascript api, apart from https / mac support / network dymo:
– Get Printer Queue and Status such as “Out of Paper”.
– Ability to Cancel Queue record
This would solve a lot of headaches we have with printing using Dymo.

Hi Riccardo, Can you provide more details on your set up? We have tried to reproduce the issue where GetPrinters is not showing shared printers as part of the list and have not been able to reproduce internally.

I am getting the dreaded “Error: DYMO Label Framework Plugin is not installed” today and have done as you directed above, in changing the settings in Chrome. I have shut down and rebooted, and it still does not work. Please help! I need to print labels!

Hi Melissa, Have you installed the Web Service or just changed the settings in Chrome? It looks like you only changed Chrome settings which will not work in the latest version of Chrome since NPAPI has been completely removed in the newest version and you will need to use the Web Service.

The removal of NPAPI only centers around Chrome at this time. The DYMO plugin for IE is based on ActiveX so make sure the client allows the ActiveX plugin to run for the application to work. The Framework 2.0 that we have provided a Beta for is browser independent and does not use ActiveX or NPAPI to operate.

Got beta up and running pretty well, although ideally need network printers to work but can manage without for now.

With regards to HTTPS issues, as a temp fix you can add –allow-running-insecure-content flag to chrome short-cut so that the user doesn’t need to manually accept unsafe scripts. Not ideal as you don’t really want the setting for other websites, so works best using a chrome app.

Hi Scott, We are trying to reproduce the problem with network printers not showing up in the printer list. We have been unable to reproduce this, we have shared a printer from one machine, installed it on another machine. This printer will show up in the GetPrinters list and we successfully print to it. We have done this on a number of configurations. Could you provide more information on your set up to aid us in reproducing this issue?

4. DATA COLLECTION/PRIVACY POLICY:
The Program offers a data collection feature that collects data based on your use of the product, including, without limitation, the operating system, number of labels printed, how often labels are printed, and the types of labels printed. The Program sends this data to a central server where the data is aggregated. This data will not contain personally identifiable information. Use of the data is subject to our privacy policy available at dymo.com. You may opt out of use of the data collection feature during installation of the Program or at anytime thereafter. This paragraph may not apply to all versions of the Program.

It has been our experience that it does. The issue was originally found on Windows 10 and it was fixed with the patch. If you our encountering problems installing the patch, you may need to contact Microsoft for support.

*sigh* We use this printer as part of our fulfilment process, without it we can not ship product. Today, Chrome updated and killed our setup.

I pulled down the service, installed it, got the latest javascript, integrated the changes into our software. Well, our software runs as a Chrome Packaged App. This Dymo code uses synchronous XHR calls which are not allowed with packaged apps (why are you doing synchronous calls anyway??). (see “Synchronous XMLHttpRequest” at https://developer.chrome.com/apps/app_deprecated)

Well, the Dymo Javascript code is too obfuscated so I can’t hack it to use CPS or promises. Hopefully I can figure something out over the weekend so that our shipping team isn’t dead in the water come Monday.

One snag we’re hitting – we’ve had users reporting that, after upgrading to Windows 10, the web service no longer works (i.e. printing doesn’t work through any browser as my understanding is everything will use the web service if it’s available).

As a result we’ve had to advise users to uninstall the web service and use a non-Chrome browser.

Windows 10 plus the web service works fine on my machine but just ran into the third user that’s hitting this snag. Any thoughts here?

Hi Cesco,
We are still hard at work trying to get the Mac version in shape for release. We have run into some roadblocks but we are close to resolving those issues. Our hope is to release something soon, but I can’t confirm a date. I apologize for this inconvenience, we had planned to release something before now but Mac OSX isn’t cooperating. ;)

Currently in the editor you cannot save a label with multiple fields containing the same reference name.
e.g two address fields with the reference field user_addr, it will rename the second to user_addr_2

If you bypass this by modifying the xml by hand, you run into another issue, the api only will select the first reference name element.

If possible I’d love to see the editor fixed to allow this behavior, when creating labels from templates we often have mirrored labels or the same information in multiple locations with a single reference name.

I modified the api with the following small changes to allow this:

replace setObjectText with: http://pastebin.com/k2jRKzFs// sets text content for an object. Depends on object's type the content and/or text formatitng are set differently:
// - for Address the formatting is applied on line-by-line basis using list
// - for text the formatting of current first character is used for the whole text
// - for Barcode object it is barcode string
// - for Image it is base64-encoded string of image's png stream
// - for CircularText it is object's text
// - for DateTime and Counter object it is object's PreText
// - for other objects an empty string is returned
// Parameters:
// objectName - object name
// text - plain text string for new object content
function setObjectText(objectName, text)
{
//var objectElem = _getObjectByNameElement(objectName);
//var objectType = objectElem.tagName;

case "ImageObject":
// if image is embedded return it (base64 png stream)
var imageElem = Xml.getNode(objectElements[element], "Image", null);
if (imageElem)
Xml.setElementText(imageElem, text);
else
{
// if there is no tag then there should be
// so replace with
var imageLocationElem = Xml.getNode(objectElements[element], "ImageLocation", null);
if (!imageLocationElem)
throw new Error("setObjectText(): is expected but not found: " + Xml.serialize(imageElem));

//ObjectNameCmb is combobox.
There is sample code retrieves all name of object and select it.
ObjectDataEdit.Clear();
// all items first
.Items.Clear();
if (_label == null)
return;
foreach (string objName in _label.ObjectNames)
if (!string.IsNullOrEmpty(objName))
ObjectNameCmb.Items.Add(objName);

We are putting together a package that will fully support HTTPS and Networked/Shared printers. We apologize for the huge delay but there have been a lot of difficulties in getting these features to work correctly, in particular the Network/Share printers feature was very problematic. We have solutions to both issues and will be releasing a new package either tomorrow or Wednesday depending on getting a stamp of approval from QA. This will posted in a new blog entry.

I would suggest making a label using DLS (DYMO Labeling Software). With DLS you can select the proper paper and layout the label object exactly the way you want, you can then examine the xml file to see what value to use for the paper.

I’m trying to test printing using the Beta and I’m stuck at the moment.

I’ve installed DYMO Label 8.5.1 and the DYMO Web SErvice Beta Installer. I can get the DYMO to print when I enter the DYMO Label Framework JavaScript Library 2.0 Beta into the Console in Chrome, but I have to do this each time I open Chrome. Is there a way to automate this somehow? I’m not too familiar with using JavaScripts.

Hi Joe, The JavaScript library that we provide is for developers to writer their own applications for the Web. Here is a link that is an Intro To Web Development. You’ll find descriptions for CSS, HTML and JavaScript. We also have a post on Deployment of these applications.

I am an owner of a uBreakiFix store, and we are trying to use the Dymo Labelwriter 450 Turbo to print labels from within our company portal/website. We have our own DEV team in house who build this POS portal software, and they tell me that there is a known issue with the Dymo Web Service not working. I was directed here, and in conjunction with my dev team we tried instituting all the fixes and work arounds stated above. We still get the same problem, when we try to print it we get a pop up window that says it does not detect the Dymo Printer. I have downloaded the latest Web Service Beta 2, I have tried to install the patch KB2954953, but one of the service fixes does not apply. The first one, “Microsoftfixit20131” does not get fixed. I have made sure that Chrome is up to date, as well as all windows updates. I even made sure the ports for the web service tool are opened on my router. I am at a loss, please help!

Yes I do. I have also tried installing the latest beta2 that does not require the windows fix. I have also tried installing this Dymo printer on 3 different windows 10 machines in the same office. I get the same result every time. My corporate developers are telling me that since chrome disabled NPAPI that this DLS is supposed to fix the issue but it does not. Every time I try to print to the Dymo printer it says no dymo printer installed.

On a machine that has the latest DLS installed, as well as, the second version of the Beta, there is a tray icon for the web service. It looks like a stylized “D”. If you right click on that icon, there is a diagnose option. What does that return? Also, is your application using the newest version of our Javascript library linked in the Open Beta 2 post (not this one) and is your Javascript using the new “init” method defined above?

Any specific timeline for releasing the actual updated software so we can continue printing via our browser app in Chrome? Right now our workaround is to use Firefox in order to print labels from our custom software, but Firefox doesn’t handle the rest of the software that well. I don’t want to get stuck trying to use the beta right now either. I would prefer to wait until the final product is released. Do you know when that will be?
Thank you

We do not currently have a Mac OS Beta available. We are still working on it, there have been some issues that have caused a delay in the Beta release We hope to have one soon but unfortunately, I do not have a date available.

Hi Evan, our developers our having some problems reproducing this issue. Could you send a copy of the code that causes this issue to our support mailing list? sdkreply At newellco dot com Could you also add what OS that you are running on and any other information that could help us reproduce the issue. Thank You for your help!

Hi guys. I’m new to this, and I’m trying to get things working using Chrome.

I installed all the new bits and pieces mentioned above. The webservice installs ok, and seems to be running ok. I modified the “Checkenvironment.html” in the samples to reference the NEW 2.0.2 js file, however, when I click the button I keep getting the following error:

Hi, we are using the js library and it works perfect with an usb atteched Dymo 450.
When we are sharing this printer on the network (Windows Network sharing) the Dymo Label Web Service on another computer can not find the shared printer.

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.

Are there any updates on “not recognizing networked printers”? Thanks for your help.

I am not sure if you guys can help with my situation. I am trying to get a Dymo printer to print information from a Google doc. The information will be coming form select cells and printing on a custom format. We can currently print them from excel. However, we are doing this countless times throughout the date. So we would have to download the doc and pull the information that way. Is it possible to get away from downloading the doc and go straight to printing our required information?

We’d sure love to use the DYMO Label Framework Javascript Library but the licensing is unclear and not specified. The top of the JS file simply states “/*Copyright (c), 2011 Sanford, L.P. All Rights Reserved.*/”. There is no license granted for any site to use this software or include it in any SaaS system. That’s obviously problematic should you want us to use this library to communicate with our existing DYMO printers. Could you please have your legal team take a look at providing a license for developers to use the library under a common license such as MIT or Apache.