Inside Technique : Legacy Data and the Web: More fun with objects
By P.C. McGrew, EDPP and W.D. McDaniel, EDPP

When last we met we looked at graphics and how they fit into the adventure of getting to the web. We're almost ready to put the whole thing together, but before we do there is one last object to review. This time we need to look at electronic overlays, forms, form overlays, electronic forms, or whatever you want to call them. They are those objects that are generally stored as files, either in a designated directory or on the printer, which are used by reference. They are often the equivalent of what we used to think of as the preprinted forms, though at times there are both preprints and electronic forms involved in the same print job. Part of the trick in getting to the web is making sure you get all of the pieces that got to the printer!

Oh, yes. This does mean yet another extension to the lists you've been making, and this one could get a little bit complicated. Let's start with the vendor-specific file formats and then take a look at the systems that might have created those forms.

In an IBM environment, printing to IBM, Oce, Siemens, Lexmark, or even Xerox AFP printers, your electronic overlay is actually called an Overlay. The overlay is a special file format defined in the AFP architecture. The overlays are referenced in the print job so that one copy is stored and they are repeated for each page as defined in the print job. An overlay can contain text and graphics in any of the available AFP formats. Remember these fonts as graphics as you review the lists we talked about in the earlier columns. The fonts and graphics that appear in the overlay may not be used anywhere else in your print environment. It's also common to find forms that contain text blocks that are really graphics, either to use a special font not available on the printer or to make the text significantly smaller than the type sizes available. As you look at the Overlays review them for anomalies like this.

Also watch for the orientation of the overlays. In an AFP environment the overlays can be portrait or landscape, and within the print job you may also see some that are upside down. If you have ever looked at a legal contract or insurance policy you might notice that many are bound at the top so that if you lift the page the text is technically upside down on the page, but you can read it because of the way the page appears to you when you lift it. That is accomplished in business printing by a technique called tumble-duplex. Remember that if you have Overlays that are stored upside down in your library you will have a few challenges getting them displayed in a usable manner on a screen.

AFP Overlays are usually identifiable in PC environments by the extension OVY or OVL. In MVS and VM environments you will usually see an extension or filetype of OVERLAY. They are usually found in a dedicated library, and there may be more than one. You may find a single production library or you may find that the file system has been set up so that each product you print draws from a separate overlay library, just as with your fonts and graphics. Notice that we haven't talked about what created them yet. We'll get back to that in a moment.

In the Xerox printing environment using LCDS devices to print DJDE and line data or metacode print files we have electronic forms, often called by the initials FRM. This comes from the extension you find them under on the Xerox printer's hard drive. FRMs are specially formatted files which are called by reference in the print job. As in the AFP world, the FRMs contain fonts and graphics, some of which may be unique to the FRM environment. And we also have the use of the tumble-duplex technique to accomplish insurance and legal printing. All of the same concerns apply. Identify any of the unusual features of your electronic forms as you make your list.

So we have AFP Overlays or Xerox FRMs for electronic overlays. Either one may be composed of text only, text and image, or image only. In that last case you might see a full page raster image wrapped with the code to identify it as an electronic overlay. This is an important distinction since the text in the image may not come through a transform to a web format and still be readable. There is a huge difference between the resolution of text in an image at 240 dots per inch or 300 dots per inch on a high speed printer, and the 72 dots per inch (approximate) on a screen. Make sure you identify any of these types of electronic overlays and label them as potential problems.

Now, let us take a look at what might have created those electronic forms. If they are older they were probably created used a command-driven language. In the AFP world you might have used the Overlay Generation Language (OGL). In the Xerox world you might have used the Forms Description Language (FDL) on the Xerox printer or the Host Forms Description Language (HFDL) on an IBM mainframe to create and compile the electronic forms. In this case the forms development was a trial and error process. You put commands into a file with coordinates to draw lines and boxes, placed the text and graphics and ran a program to generate the electronic form format. Then you had to print it to see if it was correct. Not efficient, but it was the only way available. If this is how your forms were developed, be sure that the forms you make available for the move to the web are the production versions and not the test versions.

Then came the dawn of third party vendor solutions, and we began to see more forms design workstations. Older equipment like the Intran and Tyrego systems with dedicated workstations and special monitor cards gave way to PC-based systems like Elixir, Isis, and others. If you use a forms development workstation that is on a PC platform you will want to be sure that the forms you move into the web process are the real production forms and not something sitting in a test or development directory. the good news is that most of the forms developed on the PC will use fonts that will be web-friendly.

That takes care of the electronic forms, but you may also have pre-printed stock. You'll need to take a careful look at what you print and find out what, if any, pre-printed stock is used and if it is an integral part of the what you need to display. Often there are large blocks of text in the pre-printed form that you must reproduce to provide a valid display version. If this is the case, find out who created the masters and what format they are in. Make another list, check it twice.

Now to the tricky part. The prime method of making legacy data available on the web is to put it through some type of transform program to convert it to HTML, XML or PDF. The good news is that there are a bunch to choose from, and most are well tested in the trenches. (We'll start talking about them next month.) The bad news is that they are not usually configured to handle the addition of pre-printed overlays, though they generally handle electronic overlays. Keep this in the back of your mind as you start looking at your real requirements for moving your legacy files to the web.

The holidays are upon us, so we'll stop here and head for the egg nog. Next month we'll start doing something with all of these lists. We'll start with alook at the applications that will be the easiest to move, and some of the products that might help you get there while retaining your sanity. As always, send your questions to siteexpert@mcgrewmcdaniel.com.

Copyright 1999 McGrew + McDaniel Group, Inc. 

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