CGM Converter

to review…

From the résumé:

Client: Navistar International, Inc., Parts Catalog division.

Problem: S, a Navistar employee, was responsible for receiving CGM-formatted graphics from an outside vendor and converting them to PICT format for use in an automated catalog system. The existing solution crashed frequently, and converted 2–3 files per minute when it worked.

Solution: On my own initiative, I started a weekend project that Navistar enthusiastically embraced, to make a CGM-to-PICT converter. The finished product (full-time about two months, half-time about eight) is fully AppleScriptable, Carbonized, batch-processes at up to 10 files per second, identifies mouse hotspots, and produces QA logs (it turned out that about 5% of the vendor’s files were corrupt, but S could never prove it).

Result: S’s work is no longer dominated by this one task. He can give reliable productivity estimates, and hold suppliers to quality standards. He also likes his job better.

in detail…

The workflow for CGM files was straightforward. Navistar’s engineering CAD drawings were sent to a graphics vendor for archiving. Navistar's Parts Catalog operation would ask the vendor for selected drawings. The vendor would do some processing (such as stripping-out the drawing frames), convert the drawings to the Computer Graphics Metafile (CGM) format, and deliver the results to Navistar. Parts Catalog would then do the further processing and format conversion needed to use the images in its interactive-catalog products.

Before this project, the format conversion, from CGM to Macintosh PICT, was done by Corel Draw, which could open files in the one format and save them in the other. An AppleScript script would iterate through a folder of CGMs to automate the process. This took about twenty or thirty seconds per image, as Corel Draw was not intended to be a scriptable tool, and so attempted to display every drawing as it was first opened and then converted. Some of the CGM files were damaged; some were as large as 5 MB; and Corel Draw was expected to process hundreds or thousands of files consecutively without relaunching. On any given overnight run, it could be predicted that Corel Draw would crash, possibly bringing the machine down with it, but it could not be predicted how many drawings it would process before it did.

The “further processing” included not only cropping and graphical touch-up, but the placement of hot-spot buttons on top of callout labels in the drawings, so that customers could pull ordering information from the drawing with a mouse click. This required not only correct placement and sizing of the hot-spot, but proper labelling, so that pressing the button would generate the corresponding key for the parts database.

This was done by hand, with a Hypercard stack. The stack imported a folder full of PICT files, one per card, and had a script that allowed the operator to click at the center locations for the consecutively-numbered buttons on each card. The operator then had to clean up errors or cases in which the callout numbers in the diagram were not strictly-ascending integers. The process was long, tedious, error-prone, difficult to train, and therefore, expensive.

Solution

CGM Converter solved all these problems. The user could point at a directory containing thousands of CGM files. CGM Converter would convert these to PICT files at the rate of 10 files per second (on a 200 MHz PowerPC). When a defective CGM file was detected, it was skipped, and the name of the file and the nature of the defect was logged. This QA log could be sent back to the vendor with specific instructions on how to repair the defects.

CGM Converter detected the area of the CGM actually used — whether in integer, fixed-point, or floating-point coordinates — and scale the resulting PICT file to show the picture at a standard size.

Additionally, CGM Converter would identify the callout markers in the original file, and convert their locations, shapes, and label content into PICT comments, which another utility could convert into hotspot buttons.

CGM Converter was written in C++ using Metrowerks's PowerPlant application framework.

What Went Right

• The program does its job better, more reliably, and orders of magnitude faster, than what it replaces.
• It is easy to use.
• It is easy to extend through AppleScript.
• Its output is useful for the original purpose, and, because it is in the standard format for the platform (TEXT and commented-PICT files), easy to extend to new uses.
• Subsequent engineers have found the program easy to maintain and extend.

Limitations

• There was never enough time to document the project and its architecture fully.
• Major CGM primitives (bitmaps particularly), while they had not yet been encountered, were never implemented, leaving the product open to an “attack” from the vendor suddenly adopting their use.
• CAD-vendor-specific extensions to CGM for layering, which would have been helpful in identifying hotspots, were ignored as being too hard and uncertain to reverse-engineer.
• The interactive-mode highlighting of elements in the browser and preview pane was not commercial-quality, though adequate for debugging both CGM files and the application.