Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!tektronix!tekecs!brucec
From: brucec@tekecs.UUCP (Bruce Cohen)
Newsgroups: net.micro
Subject: Re: Re: Graphics standard needed
Message-ID: <2241@tekecs.UUCP>
Date: Fri, 30-Sep-83 18:23:44 EDT
Article-I.D.: tekecs.2241
Posted: Fri Sep 30 18:23:44 1983
Date-Received: Sun, 2-Oct-83 03:27:00 EDT
References: pyuxnn.124
Lines: 41


I would not call NAPLPS a *graphic* standard.  Rather it is an image
or picture communication standard.  The difference is not trivial.
Graphic standards or would-be standards to date have been attempts to
provide a standard method of describing an abstract set of objects in
an abstract graphic coordinate space, using some fairly universal set of
primitive operations like line, curve, etc.  These abstractions were
deliberately as device-independent as the designers of the standard
could make them.  Thus GKS or Core can be displayed on plotters,
directed beam tubes, DVSTs, or raster displays.  Also, the standards
try to deal with the sorts of abstractions that the application
programs running on them use.  Thus you can deal with relatively ideal
lines of (near) zero thickness, etc.  Editing graphics is easy, in
general.  To take out a line from a graphic object, remove the
description of the line from the list of graphic primitives in the
object.

NAPLPS is a device-dependent drawing protocol kludged onto the standard
techniques for transmitting character-coded alphanumeric and terminal
control information.  The resultant pictures are inherently raster
oriented, are described in a pixel space, rather than a
device-independent coordinate space, and suffer from the same sorts of
side-effects as terminal control codes (relationship to the cursor,
scrolling, protected text areas, etc.)  Editing is highly complicated
by the admixture of characters and graphics, by the complicated parsing
required to determine the meaning of a given character, and by the
side-effects.

My point is not that NAPLPS is a bad standard (though I have some
reservations about parts of it), but that it was not designed for use
as a standard interface to graphic utilities, or as a standard
description language for building and editing images.  Rather, it was
designed for the efficient transmission of already created pictures.
The typical operation of a videotex system, which is what NAPLPS was
developed for, is to fetch a data stream representing a picture from a
database, and send it to a terminal.

				Bruce Cohen
				UUCP:	...!teklabs!tekecs!brucec
				CSNET:	tekecs!brucec@tektronix
				ARPA:	tekecs!brucec.tektronix@rand-relay