INLINE SUPPORT FOR VECTOR FILES:

Engineering Drawings on the WWW

Author

Jodi Moline, Research Associate

Panel Members

Gary B. Rohrabaugh, President, SoftSource

Robert Finch, President, Alpha systems

Table of Contents

• Abstract
• Introduction
• Important Objectives
• Considerations for Mosaic
• Credentials
• Biographies

Abstract

Criteria must be established to examine existing vector formats and standards. A determination must be made as to whether or not existing standards support sufficient entities and contain enough detail without being too complex. The file format must optimize size, transmission and display speeds minimizing overhead on the network. If no existing format is deemed viable SoftSource will define and produce a new one.

A lively discussion should be generated by the file format issues important to designers, business and manufacturing communities. The discussion will have a direct impact on the resulting vector file format for inline documents. SoftSource intends to make public the vector file format and an HPGL-to-SVF translator. SoftSource will also build tools for displaying SVF in Mosaic.

Vector support for inline documents will give the manufacturing, designing and business communities an opportunity to solve design and manufacturing problems collaboratively -- between departments, with customers and outside contractors. Vector support for inline documents should dramatically reduce product design cycles, shorten procurement, and eliminate many engineering changes through collaborative engineering.

Introduction and Background

The Internet is a common way to have everybody networked. Indeed, Mosaic is now being used extensively by large corporations, consortiums like CommerceNet, Universities and Government Agencies and serves as an agency-wide network access system. Home pages in Mosaic allow outside vendors and customers to access information about the company and its products. Currently, Mosaic has the ability to inline thumbnail sketches of raster files. However, there exists a need to provide vector file support to HTML documents. When a vector file format is available for HTML documents, companies will have the opportunity to streamline the communication of engineering and design information.

In recent years the field of computer graphics has exploded as personal computers and workstations have acquired graphics facilities surpassing even those seen on supercomputers a few years ago. Currently there exist two principle, though very different, methods of representing graphic images: bitmaps (also called raster or pixel maps) and vectors. Bitmap formats work well for images with complex variations in colors, shades or shapes such as photographs, paintings, and digitized video frames. Vector representation means describing an image as a series of lines or shapes. Vector formats work well for line art such as GIS maps, scientific data, financial charts, facility layouts, architectural and engineering designs (CAD). One advantage of vector files over raster files lies with the fact that vector files are scaleable; you can easily zoom in on the details in a large map for instance.

The growing need to include vector files as inline documents highlights the necessity to reduce transmission and display speeds. Currently, unless you have a very fast connection to the Internet, transmission (download time) is slow and, unfortunately, display times usually take longer. A logical first step in the solution to vector file support in HTML documents would involve examining existing vector file formats such as HPGL and existing standards such as DXF, CGM, IGES, and PDES. A set of criterion would be established to determine whether or not any of the file formats and standards can be made fast for transmission, display and output speeds. We must also decide whether or not these standards and file formats support a reasonable set of entities (lines, arcs, circles, etc.), if they contain enough detail (fill, color, and so on), are too simple or too complex.

If the initial research into existing file formats does not provide a clear solution to a fast, scaleable file format that is viable for inline vector-based drawings, SoftSource will help define one. SoftSource will establish a scaleable Simplified Vector Format (SVF) and make it public. SoftSource will also make public a translator from SVF to HPGL (Hewlett Packard Plotter Language) and provide the appropriate viewing tools for Mosaic. SVF has the potential to enable business, industry and consortiums like CommerceNet, to shorten procurement cycles, shrink development cycles and eliminate costly changes through collaborative engineering.

By asking the design, business and manufacturing communities what are the important maintenance issues surrounding file storage and translation we can further establish the criterion for SVF.

Important objectives to consider.

• Examine existing vector file formats.

Can an existing file format be made scaleable to enable low overhead on the network? Can the transmission, display and output speeds be dramatically reduced making it suitable for inline documents? SoftSource will look at adaptive compression schemes to define the criteria for optimizing an existing vector file format (such as HPGL) for size and transmission speed.

• Examine existing standards.

SoftSource will look at existing standards, such as DXF (the de facto CAD standard), CGM IGES and PDES. We will research the entities they support: lines, arcs, and circles, etc. and determine if they are adequate. SoftSource will also determine if they contain enough detail: fill, color, and resolution and if they are too simple or too complex.

• What manufacturers and designers want.

What do manufacturers and designers want and need in terms of vector file viewing capabilities in HTML documents? How, if at all, are companies currently solving the problem of viewing vector files in Mosaic?

• Which is more relevant: speed of transmission or speed of display?

Transmission and display speeds are important decision making points in determining file size. Efficiency will depend on simplicity.

• What are the issues surrounding maintaining two copies of a drawing file?

In other words, would customers be willing to keep two copies of the same vector file around -- one that is saved in the native file format, and one that is saved for inline documents? Are there serious hardware, software or memory constraints to maintaining two copies of a drawing file? Is the amount of disk and memory space a CAD file uses up an issue? Would translating existing vector files to another file format for viewing in Mosaic be a drawback? If the translator came with Mosaic would this be perceived as a plus? How much resistance is there to downloading and installing new and/or additional software?

Considerations for a Mosaic user interface.

• Would Mosaic users like to zoom and pan on the inline drawing?

• Should controls be included with Mosaic or should these features be saved for an external viewer?

• How should hyperlinking within the vector file be handled?

Credentials

Author Biographies

Gary B. Rohrabaugh

Jodi Moline

Robert Finch