thender@uxh.cso.uiuc.edu (Todd Henderson) (04/06/91)
Dear group, I was wondering if anyone could point me to a PC or Mac based (preferably PC based) application that can edit CGM files that come from Starbase. Currently we use Lotus Manuscript for our publications and it seems to read, preview and print them just fine. However, I have tried to edit them with Aston-Tates Applause II and it won't seem to read them. Does anyone know of an application like Applause II or Harvard Graphics, etc. that we can bring a CGM file into and edit with the nice detailing provided by these then export it again. I have tried both the TOPS standard option(I think that is what it is) and the default when creating the CGM file from starbase and it does not seem to like it. Oh, by the way, I just tried to move a Applause II CGM file to the HP and use the starbase utility to look at it and it worked perfect. Any ideas why the reverse won't work. Any help is appreciated. Thanks in advance. Please send responses to: hender@uicfdc.aae.uiuc.edu or post to this group. I read it pretty often. Todd Henderson. Most of everything I have written above is copyrighted by someone. They deserve all the credit for it, good or bad. I don't endorse anything or anybody, and I do not speak for anyone except myself. And most of the time my wife speaks for me. So I guess I speak for no one.
mbk@netcom.COM (Miles Kehoe) (04/06/91)
You will probably find that HP Starbase CGM's probably use some private codes (tags) and the reader can read files which don't have the private tags.... I think Harvard Graphics MIGHT ignore tags it doesn;t recognize... Try it first - pick it up ar Egghead and buy it conditionally..
edm@hpfcmdd.hp.com (Ed Moore) (04/09/91)
I suspect the following explains some of the difficulties you have
encountered. Not that it solves them, of course.
CGM: The Nonstandard Standard
1/29/91 PC Magazine, page 245
If there is a vector file standard for illustration and presentation graphics
uses, it is the Computer Graphics Metafile (CGM) format. Unlike other PC file
standards such as PCX or .WK1, which were originally proprietary formats that
became accepted through wide use, CGM was an intentional act. Developed by
the American National Standards Institute (ANSI), it was conceived from the
beginning as a common, public format for interchanging graphics files.
Though the details of the various proprietary vector formats can differ
widely, the ANSI team was able to rely on the fact that all vector-based
graphics images are made up of sets of common elements (or primitives). The
CGM standard supports several major types of primitives: lines (which may
include polylines or arcs), fill areas (which include both circles and
ellipses as well as polygons and rectangles), and text.
Each of these, in time, are assigned attributes, such as line color and style,
fill style or hatch pattern, and character size, type, and orientation. As a
true metafile format, a CGM file can even incorporate bitmapped images along
with vector objects, though few software packages actually support these
so-called "cell arrays." By codifying the rules that govern how the primi-
tives are placed into the file and proposing standard schemes for encoding the
file itself, the ANSI standard makes it possible to use vector images in any
program with a CGM interpreter.
THEORY AND PRACTICE
So much for the theory. The facts of the case, however, are quite otherwise.
Though you should be able to bring a chart created in CGM format by Lotus
1-2-3 into Micrografx Designer for dressing up, then place it into Harvard
Graphics for slide creation, in practice the CGM formats supported by these
products are incompatible with each other. Similarly, a CGM file created by
Computer Support Corp's Arts & Letters is totally unreadable by the CGM
interpreter in Lotus's Freelance Plus.
Since CGM is a true standard with a published specification, how do these
variations arise? In the first instance, though the construction of the files
is indeed closely defined in the ANSI specification, there are no minimum
standards for the number of CGM features that must be supported in order for
it to be fully compatible, so programs may support different subsets of
features. Furthermore, the standard supports some variations. For instance,
though CGM files are most commonly encoded using the binary method, plain text
encoding is permissible.
Many software developers, impatient with the limitations of the published
standard, have added proprietary fills and markers and other objects, and
these deviations cannot be recognized by the CGM interpreters of other
packages unless they are specially written to support them. Harvard Graphics,
for instance, includes polka-dot and dithered fills in its CGM file format
that are not supported in the ANSI standard.
A common oversight leads to problems in image sizing. In a CGM file, the
basic properties of each primitive (including the coordinates that locate it
within the image as a whole) are stored in the Picture Description section in
the file header. A Virtual Device Coordinate (VDC), in turn, tells the
receiving interpreter the size of the entire picture. Yet some software
developers have disregarded the importance of reporting the VDC accurately,
causing images to be too small or too large when imported.
A COMPLEX REALITY
As a result of these complexities, many developers have balked at tile
daunting task of writing CGM generators that implement the full specification
in all its details, and handle all its informal variations. Though many
graphics programs claim to import and export CGM files, in fact most of them
support only a subset of the specification, and some can either import CGM
files or export them, but not both. Arts & Letters, for instance, exports CGM
files in three different commonly supported subsets.
All is not totally bleak, however. As software developers have become aware
of the variations, they have developed smart file import/export filters to
support all of them without the user having to specify which flavor is being
converted. And another light of sorts can be discerned in the GSS*CGM
Interpreter drivers offered by Graphic Software Systems (GSS) of Beaverton,
Oregon. These are program routines that software developers can incorporate
into their applications to allow them to produce files in a standard subset of
CGM. In theory, any package that incorporates GSS drivers can read files
created by other packages that use them, and hundreds of programs (including
Lotus 1-2-3, Release 3.1) do so.
Even as it finally becomes a usable standard, the march of technology is
leaving CGM behind. The current specification, last updated in 1986, does not
support such important primitives as Bezier curves, and conversions from more
full-featured proprietary formats inevitably leave much to be desired. With
the increasing popularity of Windows 3.0, CGM's place as a vector standard is
being challenged by the Windows Metafile (.WMF) format that is supported by
all Windows applications.
Extensions of CGM have been proposed that would add more-sophisticated
primitives, support vector clipping, and allow the inclusion of 3-D images in
multiple views. But how long they will take to arrive, and whether they will
be sufficient when they do is an open question. In any case, it is to be
hoped that a new specification would make some attempt to standardize existing
CGM implementations and prevent new variations. Only by this means can a
semblance of unity be brought to this useful, but muddled graphics format.