Inside Technique : Legacy Data and the Web: The Adventure Continues
By P.C. McGrew, EDPP and W.D. McDaniel, EDPP

First, we'd like to thank those of you who have been sending notes to us. We have had more response than we anticipated, which tells us that a lot of you are still struggling with the problems that many of the industry trades believe has already been solved. Keep on writing and letting us know what you need to know. We'll try to cover it all.

In the last episode we took a hard look at font variations and made more lists of things to worry about as you begin migrating legacy data. Lists aren't fun, but they will become invaluable as you move forward. Notice that we're still making lists and we haven't discussed a lot in the way of solutions as yet. Hold on, we will get there. But we still need to take a hard look at another resource found in much of your legacy data: graphics.

The term graphics means a lot of things to a lot of people. For the purposes of legacy data you may find that there are vendor-specific graphic file formats and there are even graphics encoded into font formats. We did all of these things to ourselves in the quest for faster-printing files, and now we have to dig our way back out. 

Let us start with the obvious, the vendor-specific graphic file formats you are likely to encounter. 

In a Xerox environment there are several variations on their LCDS machines, and there are also those XES/UDK machines still in use in many places. The most common Xerox printers, though, are the high-speed printers, usually printing on cut-sheet paper, that were born with the Xerox 8700 using line data mixed with Dynamic Job Descriptor Entries (DJDEs) or Xerox Metacode to achieve print. In this environment your graphics may be embedded in a font, encoded in a file format called a LOGO (extension .LGO), or created as an Image file (extension .IMG). Since the very first incarnation of the 8700's had limited disk space and limited memory, Xerox tried to find ways to encode graphics into the files using the least amount of the available processing resource.  This was the birth of the use of the font file format to place a graphic on the printed page. 

The limitation on using a font file to place a graphic image was that you had to have your composition program, whatever it might have been, make the call to the font file and place the specific characters containing the pieces of the graphic into the output print. Not impossible, but not trivial.  To make it a bit easier Xerox provided the .LGO format, which was a Xerox font file in which the graphic characters were pre-loaded. That meant you could simply call the .LGO file and the graphic would appear in the output.  Sounds great and worked great.  It is, however, difficult to migrate. The problem is that the web really doesn't understand the .LGO file format, let alone the Xerox font file format, so we have to make some decisions about the best way to get that graphic into the new output file. 

Xerox also supports a raster file format called a .IMG file (not to be confused with .IMG files from some PC graphic programs). As the Xerox machines became faster and included higher storage and memory capacity, the use of the raster file format became more popular.  More and more graphic programs became enabled to produce the format, and graphics dotted more and more of the output print files. Again, though, this raster file format had a bunch of variations and is still distinctively a Xerox file format.  You don't just ask your web browser to take a look at it and render it; most cannot. And remember that all of this involved raster data, bitmaps, for the graphics. There is not a Xerox vector file format, so these files grow as the size of the graphic image grows. Xerox raster files and font/logo files are stored at 300 dpi  in most cases, though some machines support 600 dpi.  

Moving on to the Advanced Function Printing Environment we still may find graphics encoded into one of the font formats, as we described last time, or they may be contained in something called a Page Segment (PSEG or .PSG) file. In the beginning this was a wrapper for a raster file format, but over time as the Advanced Function Printing Architecture grew, it became a wrapper for vector formats as well. So, in an average AFP environment, regardless of who makes the printer, the graphic files may be older style PSEGS encoded at resolution of 240 DPI. It is possible that in some of the oldest environment you may find files encoded at other resolutions, like 120 dpi or even 400 dpi, but for the most part the early days of AFP were 240 dpi days. As time passed AFP began to embrace the 300 dpi and even 1200 dpi resolutions.  Yes, that means you have to be on the lookout for everything. 

Since IBM not only makes printers, but also lots and lots of software, there were always products in the mainframe shops capable of producing some type of graphic file format, and most could be edited into something that the AFP printers will print. AFP PSEG files can not only wrap raw raster data for printing, but also a number of additional AFP architectural components, such as IOCA (Image Object Content Architecture) files, which are a raster format, and GOCA (Graphic Object Content Architecture) files, which are vector format. 

And remember, the oldest files will probably be pure black and white images, but spot color/highlight color, and maybe even process color. So, like we did for the font issues last month, here are the kinds of things you need to be looking for and writing down.

Graphics	Issues	Web
Xerox .FNT	There are normally 300 dpi files containing text characters, but in some cases customer coded graphics into the character values to create corporate logos that would print faster than a raster graphic.	You could have a font made that matched, but you would have to ensure that it was available to every machine's browser or use one of the new technologies for encoding the font into the HTML/PDF file.
Xerox .LGO	The Logo files are really font files with a bit more information in them. The identify the order of the characters needed to create the graphic correctly.	Same as above, though the file extension and formats need to be web-compatible.
Xerox .IMG	This is a raster file format that is normally at 300 dpi but maybe at 600 dpi in some cases.  IMGs were traditionally black and white, but color has been creeping in rapidly over the past five years, so watch out for all possibilities.	You have to turn the file into something that a browser can deal with, usually a GIF or JPEG, perhaps even a PNG. Here you will want to take care since you may encounter quality issues and file size issues as you transform the graphics.
IBM PSEG3820	While most Page Segment files contain 240 dpi black and white graphics, there have been many variations over the years. Watch for the creation dates and the products used to create the page segments.  The more you know about what created them the easier it will be to make web equivalents.	As above, you will have to get the file into a web compatible format.  We'll talk more about that in later columns
MO:DCA	Many people we've encountered talk about having MO:DCA graphics in their files. What they really mean is that they have one of the two formats listed below.	See below.
IOCA	IOCA went through changes over the years, so again, watch for file creation dates and what products were used.	Same as above.
GOCA	For a vector graphic format that gave you small files, it never became as popular across the board in AFP environments.   But you do have to watch for it and you do need to understand what created.	None

As much as we've emphasized the graphic files formats, remember that in many cases it is going to be easier to just re-create the graphic using new tools. You still have to know the dimensions and other physical characteristics of the graphic, and be able to manipulate it in the final file, so lists of what you have and what created them will be very helpful. 

Once again we'll break here. Next month we'll talk a bit about those things we call forms or overlays and some of those challenges.  At the end of that column we should be ready to launch into some of the solutions.  As always, we'll take questions, too! Address them to siteexpert@mcgrewmcdaniel.com.

Copyright 1999 McGrew + McDaniel Group, Inc. 

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