Inside Technique : Legacy Data and the Web: Getting Graphics to the Web!
By P.C. McGrew, EDPP and W.D. McDaniel, EDPP

You've done everything right, but what ends up on the web just doesn't look like that nice form that Moore always printed for you, or those FRMs or Overlays your forms coding department crafted over the past 10 years. Why not? You did everything correctly. You followed all of the rules.  Does the web have something against you personally? 

No. It really doesn't. The problem is that your legacy data, not matter how diligently you understand it, was made for 240 or 300 dpi laser print devices, and that 72 dpi (approximately) screen you are trying to display that data on is a few pixels short on the resolution.  So what do you do? 

The basic question is, "How important is it that the print and web form look identical?" Not just the forms, but the overall document will tend to pick up some formatting inconsistencies as they come through any transformation. This is true whether you use a transformation program that reads in your print datastream and converts it to PDF or HTML, or you strip down to the bare text and regenerate the HTML, XML, or XHTML (let alone HML, WML... those are another column).  

This is a big question for many industries.  In the insurance and financial industries it has always been taken as gospel that the displayed image must be identical to the printed image delivered via the post office. In any industry the advertising department will sing a song of color wheels and the requirements for specific shades of blue and red to convey their marketing messages. And many managers, not knowing what the research says about comprehension of documents on the web or readability and usability of documents on the web, will insist that the documents be made "light table" identical. Imagine holding up the paper to your screen and having to make everything identical. It's a tough job.  Especially when you understand that screens come in many resolutions and configurations which can change the way colors are displayed and fonts are rendered.  

So, here we are. The documents don't look the same.  Let's take the problems in categories, starting with the graphics. Why don't your graphics, which were created for your 240, 480, 300, or 600 dpi print devices look right on the screen. There are many possibilities, but start with problem identification and work through the steps. 

1. Does the image appear to be the wrong size with relation to the text around it as they all appeared in print? 
       If so, you may have a problem in the program handling the conversion or in some parameters that you are feeding it. If you are building the document from the ground up, perhaps you selected an incorrect size parameter when you converted your Page Segment, IOCA, GOCA, LGO or IMG file to the appropriate GIF file. 
2. Did the image pick up a moire pattern or become pixelated? 
       If so, look again to the transform program and its parameters if you are using one.  But also look carefully at the original image.  If it is an exceptionally complex image with many shades of gray you may not be able to cleanly reflect it in the 72 dpi world of the web.  Seriously consider remaking your graphics.  If you are in a production environment, consider have a separate library for the transform program to look at that uses a less complex form of the image. 
3. Does the image turn into a blob? 
       That's the technical way of expressing the problem associated with complex images (again!) not having enough dots to resolve into on the screen. If you notice that the screen version of an image clumps up like your cat litter, look to the solutions above. 
4. Are the colors different?
       Sad fact is that they will usually be different.  Remember that we work with about 217 colors in the ideal web world. In the color toner world we work with mixes of red, green, blue and black that are treated differently and have different chemical elements than those in the phosphorous of the screen. This is one of those places where you have to look carefully at your motivations.  Is a specific shade a requirement because some art director says so, or for some more legitimate reason? (Apologies to the sane art directors in the crowd.)

This is the time where you need to stand back and ask if getting a good, clean, crisp image is better than trying to work miracles in a world where every monitor treats the signals for red, green, and blue a bit differently, and even a change in the video card can change what you see. For most business documents moving to nice spot colors with lower resolution images is more effective at communication that pixel-shy attempts at high-resolution images. 

The rule of thumb is going to be to keep the image sizes as small as possible to keep load times effective, and to take a good look during your testing to ensure that what you see on the screen is what you expect.  If worse comes to worse and you cannot come up with a good, transformed version of a graphic, consider remaking the graphic with a web-friendly tool, then running through a product like Adobe's ImageReady to ensure that you have an optimized image, and talk with your web folks about just-in-time image substitution. 

Next time we'll look at why fonts might not look right! As always, send your questions to siteexpert@mcgrewmcdaniel.com.

Copyright 2000 McGrew + McDaniel Group, Inc. 

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.