Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ ForewordContentsPrefacePrologueAcknowledgementsParticipants1. IntroductionA. GuedjB. HopgoodC. CrestinD. WarmanE. SabinF. EncarnacaoG. DunnH. BonoI. NewellJ. FoleyK. FoleyL. SanchaM. SanchaN. Sancha2. Working documentsCurrent positionGraphics primitivesCoreAttributesStructureMethodology: StructureDesignInputTransformationsFormal SpecificationConceptual FrameworkIFIP ReportRecommendationsFuture
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDLiteratureBooksMethodology in Computer Graphics
ACDLiteratureBooksMethodology in Computer Graphics
ACL ACD C&A INF CCD CISD Archives
Further reading

ForewordContentsPrefacePrologueAcknowledgementsParticipants1. IntroductionA. GuedjB. HopgoodC. CrestinD. WarmanE. SabinF. EncarnacaoG. DunnH. BonoI. NewellJ. FoleyK. FoleyL. SanchaM. SanchaN. Sancha2. Working documentsCurrent positionGraphics primitivesCoreAttributesStructureMethodology: StructureDesignInputTransformationsFormal SpecificationConceptual FrameworkIFIP ReportRecommendationsFuture

Output Primitives

J.D. Foley

General Issues

  1. The standard should have a 2-D subset for which 1 = 0 is implicit.
  2. 2-D and 3-D primitives should be freely intermixable.
  3. The definition of a primitive must always specify how the current beam (drawing pen) position is affected,
  4. If 2-D and 3-D primitives are intermingled, the current beam position's Z-coordinate is implicitly used to establish the plane in which the 2-D primitive is placed.
  5. The following primitive attributes should be treated by the standard:
    • intensity
    • line/point width
    • line structure (e.g. dot, dash, dot-dash, etc.)
    • color
  6. A relative draw by the application program need not become a relative draw in display processor code, nor vice versa.

Primitives

What is an output primitive? what is atomic, what is molecular? I believe we should take as our working definition that primitives are those constructs which:

  1. Effectively exercise the hardware capabilities of one or more commercially available display processors, or
  2. Effectively exercise the hardware capabilities of any display processor which might reasonably become commercially available, and
  3. Cannot be effectively (i.e., efficiently) simulated on all display processors which are or which might become commercially available.

Point 1 is intended to assure that the standards framework not preclude use of currently available hardware primitives. Point 2 is a hedge against the future and is beset by problems like foggy crystal balls and excessive optimism. Point 3 is a means of assuring that we really are talking here about primitives. Of course the standard might also specify non-primitive constructs which are frequently useful (and are implemented using primitives) but our concern in this section is with primitives.

The primitives listed below are marked with a (1) or (2), to indicate the category into which I believe they fall.

  1. Position beam (1)
  2. Point (1)
  3. Line (1)
  4. Line strings (1)
  5. Circular arc (1)
  6. Elliptical arc (1)
  7. 2-D (planar) Curves
    • Conic sections (1)
    • polynomials (2)
    • splines (2)
    • etc
  8. 3-D (non-planar) curves (2)
  9. Surfaces (2)
  10. Text and symbols (discussed at greater length in later section) (1)

While circular and elliptical arcs are special cases of conic sections, some display systems have only a circle generator, or a circle/ellipse generator. Others can display general conics.

Text and Symbols

For a working definition, let us define text as the printable ASCII characters. Symbols are all other patterns which are, or might be, displayed by a hardware or software character generator under the general guise of special characters.

Dan Bergeron suggested that we consider text from two viewpoints:

  1. As a means of communicating information to the user of an interactive graphics system, often in the form of prompts, menus, error messages, etc.
  2. As an integral part of the displayed or plotted picture.

The distinction is important: in the former case, issues of font, spacing, and aspect ratio are not important, while in the latter case they can be quite significant.

Issues which we should address are:

I recommend that we do not become involved in text issues relating to font details. This becomes a graphics art and printing industry concern. At most, I would suggest that we define a means of telling the graphics package which text font is desired, with some mechanism in the standard framework for assigning numbers to fonts.

I further recommend that a standard adopt a range of acceptable defaults for all of the above character considerations, so the program using text to simply communicate to the user can do so in a simple way.

Another issue we should not consider is formatted output of numeric values. The application programmer, perhaps using utility routines, converts a number to a character string, then causes the string to be displayed.

Other issues we should not directly address are those related to typesetting, such as:

These can all be indirectly treated by use of the move primitive, and drawing single characters of specified sizes. That is, the above issues are not primitives and must therefore be ignored.

Symbols, as contrasted to text, are an even stickier widget. I have no comments at this time.

Epilogue

My comments are best viewed in the perspective set by Luis Villalobos in his article Virtual Graphic Device, Computer Graphics Quarterly, Winter 1974. Some comments supplement and others contradict the position taken by Luis.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site