Inside Technique : Legacy Data and the Web: The Adventure Continues
Legacy Data and the Web Series
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.
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
Copyright 1999 McGrew + McDaniel Group, Inc.
© 1997-2000 InsideDHTML.com, LLC. All rights reserved.