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:

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.

Some developers link directly to js library from labelwriter.com. 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.

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.

We host a lot of samples and documentation on labelwriter.com. 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.

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 http://www.dymo.com/en-US/online-support/dymo-user-guides. 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 http://www.dymo.com/en-US/online-support/online-support-sdk#.

Download Links

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:

Major Features

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

Windows

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.

Introduction

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

Server

Print From

Browser

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.

Conclusion

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.