Cheryl D. Walters

For years, the Cataloging Dept. at Utah State University searched for an effective spine labeling system. While USU Libraries had beta-tested products (thin client Sun Rays and ERes, an electronic reserves program, for example) and incorporated the latest server technology and state-of-the-art digital scanners, as of the year 2000 we still had not found a reliable technology for producing high-quality, readable, durable spine labels that adhered well to our books.

It is not that we did not try. As printing technology progressed, so too did our Libraries’ use of it: from handwritten stylus labels, to manual and then electric typewriters, to heat-adhered SELIN labels, to dot-matrix printed labels directly from Passport OCLC label screens and then via OCLC CatME and the OCLC Label program, and finally to laser-printed labels from WordPerfect label files. None of these met our expectations. We continued to look for something better. We contacted colleagues, visited other libraries, and searched the literature, but we just could not find a label and labeling system to fit all of our needs.

Finally while chatting one day with a representative from Computype, Inc. about some of their products, including sophisticated radio-frequency identification smart labels and automatic book return systems, I said “But what we really need are legible spine labels that really stick to our books.” From there I described the ideal labeling system as I envisioned it: the ability to print from any workstation; low-maintenance; offering the dark crisp print of a laser printer, but without the inconvenient and wasteful 56 label stock and the text that smeared. The font would clearly distinguish between all letters and numbers; it would be scalable to fit the label, automatically increasing or diminishing according to the length or width of the call number. Labels would print directly from the item record in our online catalog to eliminate the possibility of human error, ensuring that the label on the book always matched the call number, etc. in the online catalog. The printer would translate our various location and collection codes into understandable label headings. And of course, all of this would all be affordable and provide adhesion to most book surfaces.

A new kind of printing technology

As we talked, the salesman mentioned a printing technology called “thermal transfer printing” and a little piece of electronic equipment called a LabelMorphor which could be programmed to integrate a thermal label printer with our online catalog to create the format, font, and size of label we wanted. Thermal transfer printing, he said, is a process that uses a resin-coated ribbon and a print head with small dots called pixels that heat up and transfer the ribbon onto a label material such as polyester, paper, etc. The result is a very durable bond that resists smearing and abrasion. This technology sounded very promising. Could we use it to create an effective labeling system for our library? We decided to investigate further.

After working with Computype on specifications we developed a printing system that we implemented in March 2001. Since then we have printed over 75,000 clear, high-contrast, and easily readable labels using the font of our choice (Century Schoolbook). We have experienced no programming or maintenance problems with the printer and we rarely need to use a label protector to get a firm seal. The beautiful, crisp, easy-to-read, accurate labels adhered well to most book surfaces. So superior was this new printing system that it even won over our SELIN label aficionado who had advocated a return to cooking labels on a hotplate.

Step One

Our first step was to send the company’s programmer some sample data streams from our online catalog label screen. A data stream is simply the electronic message sent from the online catalog to the printer telling it how to format the label and what data to print. To generate and send these to the company, we would call up an item record in the catalog, format a label using regular database commands, and then instead of choosing a printer to send the data to, we choose “Generic, Text only” and save the data as a file which could be read using Notepad. We then sent these off to the programmer as e-mail attachments. The programmer determined that the data streams were compatible with (i.e. readable by) the printer we had in mind. We were off and running, we thought. And then we hit our first problem.

Hurdle One: the Font

The proposed printer ($1,545) only supported four fonts, and we liked none of them. None had serifs, the spacing failed to please the eye, and some similar-looking characters were not differentiated well enough. We insisted on clarity and the ability to distinguish one character from another because we were concerned about our patrons and reshelvers mis-reading call numbers. We chose to upgrade to a more expensive printer to get an acceptable font. Computype, Inc. found a printer (Zebra 105SE) that supported Century Schoolbook font for about $4,000. There is now a less-expensive model available from Zebra with the same functionality: the Z4M. While the font is not scalable (i.e., it does not automatically adjust in size based on the width of each line), we compromised by having the scale be one of two different sizes depending on how many characters were in a given line.

Designing the Label Format

Having selected a printer and font, we established a set of spine label rules for the Computype programmer to work from. We provided him our online catalog’s location codes for the program to translate into readable headings. For example, the location code “me” would generate the text “MERRILL” at the top of the label to indicate that the Merrill Library housed the item. In our online catalog parameters, we created label headers for each collection code so that books coded “mref”, for example, would generate the text “Reference” as the second line of the spine label.

Initially, we used two different label formats in our online catalog to generate the two different label formats we wanted: one for the spine label with just location, collection, call number, and volume enumeration and one for an “inside” label which contained the title, author, and bar code in addition to all the spine label information. We intended the “inside” label to aid in matching up the spine label with its corresponding book. Because of inconsistent line feed commands and hard returns in the data stream, the Label Morphor program Computype has developed could not always discern where lines began and ended. After much experimentation, we chose one “big label” format which contained all the elements we wanted, but in an order that allowed the Label Morphor to easily read them. We then used the Label Morphor program to move the elements to where we wanted them on the labels. The single label format displayed on the online catalog screen generated two different labels using the various bits of information provided by this one “big label” format (see Figure 1).

Developing the Specifications

Once we decided on the label format, we drafted program specifications delineating exactly where data elements were in the data stream and how they should be interpreted and printed in the two label formats. The spine label was to print vertically on the label (i.e. portrait format) while the “inside” label was to print horizontally across the label (i.e. landscape format), using a much smaller font size. The printer was instructed to interpret a period (.) in the collection element to mean that it should leave the collection name blank on the label. If certain lines were blank in the data stream, that instructed the printer to only print a spine label and not the fuller “inside” label (see Figure 3). We used commas in the volume enumeration line to generate line breaks in the spine label so that each level of volume enumeration would print on a separate line.

To maximize font size, we instructed the printer to use a fairly large default font size, but that if any line in the call number exceeded 6 characters, it would automatically reduce the font for the entire call number. We factored in line wrapping for extra long title and author lines. Unexpectedly we discovered that we could print a scannable bar code on the label instead of just printing the barcode number. We decided to place these formerly “inside” labels on the outside of the back cover so books could easily be scanned during inventory.

Label Stock

In the past we had used standard sets of label stock purchased from the usual library supply companies. Each set of labels had a narrow, long label for the spine and a wider but shorter label that we used inside the book to list its author, title and call number. Depending on the situation, sometimes we only needed one or the other of these labels instead of the set of two, resulting in some unused labels. To avoid this waste, we designed our new label formats to fit on the same size label, 1” x 1 ½”, and wrote the specifications so that we could control whether one or two labels printed. This allowed us to use rolls of continuous labels, all of the same size, with no unused labels. We had to custom order this label stock because it was not a standard size; we specified which of several adhesive types we wanted also. The one-time cost for creating this customized label stock was $588. Thereafter, we simply paid for the labels themselves.

Testing the Specifications

After testing the program internally, Computype sent us the printer, the programmed Label Morphor, and the label stock. We tested it for a month or so, requesting two programming changes which were accommodated by simply mailing us new EPROM chips which we installed ourselves with no problem. At first the hum that the printer made was alarming, but we quickly discovered that it was helpful in letting us know that our labels had printed, even when we were located across the room from the networked printer. The hum became a comforting non-intrusive background noise.

Adding a Batch Function

We tried to anticipate every labeling need while writing the specifications, but discovered that we had overlooked batch printing. When printing labels for large sets of materials, we needed a way to set up just one label, and then print many iterations of that same label. Even more ideally, we wanted to print multiple versions of the same label, but have the program automatically increment the volume numbering so that the first label said “v. 1", the second label said “v. 2", etc. We tried different ways to create this functionality and eventually settled on something fairly simple. In the volume enumeration line that normally contained volume text such as “v. 1", we would type in the word “BATCH” followed by a space, colon, space, and then a number indicating how many labels we wanted; if volume incrementation was needed, we would indicate the beginning enumeration with a ++ added to it (see Figure 2). Thus to create ten labels for volumes 1 - 10, we would use the statement: BATCH : 10 : v. 1++. We allowed for multiple levels of volume enumeration, but with only the last level incrementing. So for volume 1, parts 1 -3, the statement would read: BATCH : 3 : v. 1, pt. 1++ . To generate 100 labels that were exactly the same, the statement would simply read: BATCH : 100. Adding this batch functionality cost an additional $250.

Success!

We are still very pleased with our labeling system. No matter where you are in the library, you can print to our networked label printer. The labels are consistently clear and dark. They stick so well to most book surfaces that we rarely need to use label protectors that were used previously on almost every book. Each label order includes ribbons as well as cleaning solution for the printer. Unlike dot-matrix printer ribbons, these ribbons neither dry out nor make your fingers black as you change them. We maintain only one printer and it has never failed us. We have gone through several online catalog upgrades, one was very substantial, with no adverse effect on our printing capability. We were worried that substantial alterations in our online catalog software would require reprogramming the Label Morphor, but that has not happened.

Label Costs

Our ongoing label costs are actually less than if we were using our old dot matrix printing system primarily because we have largely eliminated the need for label protectors and no longer purchase printer ribbons since they are supplied with each label order. Our label stock, which comes complete with ribbons and cleaning solution, costs us 3.6 cents for each pair of labels. Using our former label stock would entail the following costs: 3.8 cents per pair of labels, plus 2.9 cents for a label protector, plus ribbon costs, for a total exceeding 6 cents per pair of labels.

Based upon the success of our collaborative venture, Computype worked with our database producer, epixtech, to make this labeling product available to all of the latter’s Horizon and Dynix users. But non-epixtech online catalog users need not despair; Computype also has the ability to integrate this spine labeling system with other library online catalogs.