What's Hiding in Your Labeling Artwork?

Did you know there are risks hiding in your labeling artwork documents that are invisible to anyone doing manual proofreading?

Nobody is introducing these risks on purpose, of course. Graphic designers who work either in-house or as third-party contractors for life sciences organizations face professional challenges unique to the industry. Not only do they need to create top-notch visuals, but they also need a deep understanding of the regulatory environment in which they operate.

Because it’s not realistic to assume that all graphic designers will follow all regulatory best practices all the time, it’s helpful to understand how to find these hidden risks and how to prevent them in the future.

What You Can’t See Can Hurt You

This blog post will help you understand:

• What the most common labeling artwork hidden risks are.
• How and why these risks get introduced.
• How to check your documents for these risks.
• Best practices that can help you prevent these risks from being introduced in the future.

Problem #1 – PDF Conversion Issues

Graphic designers use design applications such as Adobe Illustrator and Adobe InDesign to create labeling artwork. These design applications are expensive and complex, so it makes sense to convert the designs from the native file format to a more common document format for internal review, and also to send to the printer once the design proof has been approved.

The current standard for artwork design proofs is PDF.

Problems can arise when the recommended method for exporting to PDF from a given application is not used.

Here are just a couple of examples of problems that can arise when best practices are not followed:

• Corrupt text – Text might look fine when viewing a screen or hard copy but could be stripped of Unicode values (unique codes behind the scenes that define each character and are read by many software applications). Corrupted text can lead to problems with accessibility because text to speech applications read Unicode, and if the characters in the design proof no longer have Unicode behind them, visually impaired people will not be able to use a text-to-speech application to have the document read to them.
• Missing fonts – If the recommended method for converting to PDF is used, all fonts used in the document will be embedded, so that whoever reads the document can see it in its intended form. If fonts are not embedded, however, text could be displayed using the wrong font, or might appear simply as unreadable “garbage” characters. Font substitution can cause extra correction cycles (if somebody notices that one or more fonts is incorrect) or misprints (if the print job runs before anyone notices).

Checking for PDF Conversion Issues You can check for text corruption by copying the text from your design proof and pasting it into a text editor (e.g., Notepad). If you can read the text in Notepad and it matches what’s in your design proof, there is no text corruption.

You can also use text-to-speech to have the document read back to you. If text-to-speech works properly, there is no text corruption.

For embedded fonts you can use Adobe Acrobat (or Acrobat Reader). Go to File/Properties and look at the Fonts tab to see which fonts have been embedded in the document.

How to Prevent PDF Conversion Issues

Understand best practices for PDF conversion and the issues that can arise when those best practices are not followed. Each design application has its own recommended method for converting from native format to PDF. Make sure you adhere to the recommendations for your chosen design application.

Also, consider preflighting your PDFs before sending them to the printer. Preflighting is an industry term used to define a set of preparedness checks run against a PDF to make sure it is print-ready. Most design applications come with built-in preflight functionality, but there are also third-party tools available.

Problem #2 – Vectorized/Rasterized Text

We’ve already touched on Unicode in this article as a global standard for allowing machines and software applications to read text accurately. Vectorized and rasterized text represent two more ways that you might be able to read text on your screen (or in a hard copy) with your own eyes, but a machine or software application would not be able to read that same text.

Rasterized and vectorized text are slightly different from each other in practice, but for our purposes they both represent the same problem, which is that there is no Unicode behind the characters.

Removing Unicode from the text in a design proof should only be done when absolutely necessary. Here are some examples of ways that rasterizing/vectorizing the text in your design proofs can cause problems:

1. Accessibility – We covered this in the previous example, but again, if there is no live text in the document, people who are visually impaired will not be able to have the document read aloud to them by a text-to-speech application. If you’re planning on making any of your documents available, for example, on your website to download, then accessibility should definitely be a consideration.
2. Flexibility – Rasterized/vectorized text usually go hand in hand with a “flattening” of the document that is supposed to prevent problems once the printer has the design proof. In reality, the flattening of design proofs causes more problems than it solves. Printers sometimes need to make tweaks to a document to get things just right before running the print job. If the document has been flattened making those tweaks can become difficult or impossible.

Checking for Rasterized/Vectorized Text

This is the same as in the previous example. Either try to copy the text into a text editor or have the text read to you with a text-to-speech application. Live text will copy into a text editor with no problem and will be picked up by a text-to-speech application. Rasterized/vectorized text will not.

Problem #3 – Reading Order Issues

In design applications, text always goes in a text box, and these text boxes can get dragged around, reordered, deleted and added as a design goes through revisions. Each one of these text boxes has a “reading order tag,” and these reading order tags are created in the order that the text boxes are created. As a result, if you create four text boxes, then shift them around on the page so they’re not in the original order, your reading order tags are now out of order.

The big issue here is accessibility.

If you’re planning on making documents available to the public, you need to understand that text-to-speech applications will read the text in the order indicated by the reading order tags. The absolute best-case scenario here would be confusion. Worst case scenario would be some sort of adverse event due to out of order instructions in an instruction for use (IFU).

How to Check for Reading Order Issues

Again, this is the same as in the previous examples. Either copy the text into a text editor or open the document with a text-to-speech application. If your reading order tags are correct, the text in the text editor/text-to-speech application will be the same as what you see in your PDF design proof. If there are problems, the order of the text will not match in some places.

How to Prevent Reading Order Issues

Make sure your designers know about reading order tags and what tools they have at their disposal to edit/reflow reading order tags (options may vary depending on what applications you’re using).

It’s also important for designers to know what (if any) policy your organization has on accessibility, and what effect reading order can have on the accessibility of documents made available to the public.

Problem #4 – Hidden Text

Hidden text is text that has either a) had its color changed to match the background and is now invisible, or b) text that has been placed behind an image or another text box.

The obvious question is why this would ever happen.

There are times when designers are given difficult, or even impossible turnaround times for projects. When this happens, they have a bag of shortcut tricks at their disposal to help them get things done faster.

Sometimes, it’s easier to hide text and put new text right over the top than it is to delete and replace it. For example, maybe my medical device company has a MyDevice5000x and a MyDevice5000i where the documentation for one variation is a subset of documentation for the other. In this case, it might seem easier to simply keep the text for both versions on the title page and then hide/make visible whichever one you currently need.

Accessibility and misprints are the two potential downstream problems that can be caused by hidden text:

• Accessibility – This should be obvious by now. We know that text-to-speech applications read Unicode, and Unicode has nothing to do with the color of the text. Even white text on a white background will be read out lout by a text-to-speech application. Again, best case scenario here is confusion. Worst case scenario is an adverse event based on text that’s not supposed to be part of an IFU.
• Misprints – As mentioned in a previous example, sometimes the printer will need to make subtle adjustments to a document to get it just right before running the print job. This is especially true for jobs where the paper is not white. Sometimes, the color of the text will need to be altered slightly to ensure that it looks correct on colored paper. When this is necessary, the printer will select an area of text in the document and edit the color. If any hidden text is part of the selected text, the color of that text will no longer match the color of the background and that text will reappear. Best case scenario is another correction cycle. Worst case scenario is a misprint.

How to Check for Hidden Text

You’ve probably guessed how to do this by now. Use the copy/paste method or the text-to-speech method. Any hidden text will appear in the text editor and be read to you by the text-to-speech application.

How to Prevent Hidden Text Issues

On one hand, you’ll want to help your designers understand the downstream implications of dipping into their bag of shortcut tricks.

On the other hand, you’ll also want to help your managers understand what can happen when designers are given unreasonable turnaround times for design projects.