Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
⟶ ACD ⟶ Literature ⟶ Books ⟶ Methodology in Computer Graphics
ACL ACD C&A INF CCD CISD Archives
Further reading ⇓

□ Foreword □ Contents □ Preface □ Prologue □ Acknowledgements □ Participants □ 1. Introduction □ A. Guedj □ B. Hopgood □ C. Crestin □ D. Warman □ E. Sabin □ F. Encarnacao □ G. Dunn □ H. Bono □ I. Newell □ J. Foley □ K. Foley □ L. Sancha □ M. Sancha □ N. Sancha □ 2. Working documents □ Current position □ Graphics primitives □ Core □ Attributes □ Structure □ Methodology: Structure □ Design □ Input □ Transformations □ Formal Specification □ Conceptual Framework □ IFIP Report □ Recommendations □ Future

Graphics Primitives

Introduction

Most graphics packages for plotters and interactive use define routines or procedures for a number of graphic primitives which form a basis for the higher level graphic commands provided in the system.

There is little consistency in the definition of these primitives. To some extent this is due to the different application areas that the package is to cater for. Therefore, any recommendation must be based towards a particular application area when a choice is difficult to make. In the following recommendations, the bias is assumed to be towards refreshed graphic systems rather than plotter systems. The graphic picture is a means to an end rather than the end itself.

These recommendations are not designed as a definition of a subroutine package for graphic primitives - rather they define a minimal set of facilities that are seen to be desirable. The aim has been to define primitives which lead to good codes of practice and thus improve portability.

Our aim is to cover the following areas:

  1. Positioning
  2. Line Drawing
  3. Symbol Plotting
  4. Text Output
  5. Attributes such as intensity, colour, etc.

The recommendations are expressed in a format which has the appearance of subroutine calls. This is purely a method of specification and is not a recommendation for a subroutine package.

Motivation

For lines, character strings and symbols we have attempted to get a consistent philosophy. Thus:

  1. Points and markers have a position.
  2. Lines and character strings have a start and end point. Current position gets updated. The direction of both must be specified.
  3. Prompts are messages that have nothing to do with the graphics. They do not really have a direction or a length.

Current Position

Conceptually, there is value in defining an (X, Y) position in the current coordinate system which is defined as the current position. The abbreviation CP is used and the coordinates are given as (XPOS, YPOS).

The major motivation for its introduction is to shorten the parameter list of graphic commands by allowing the current position to be an implied parameter.

Each graphic command must precisely define the result it has on the current position, in the following descriptions, the updated current position is referred to as CP' and this has the coordinates {XPOS', YPOS').

Positioning

Two primitives are available for moving the current position to a new position. These are defined as follows:

      UPXY (X, Y)
      which sets: XPOS' = X 
                  YPOS' = Y
and
      UPDXY (DX, DY)
       which sets:  XPOS' = XPOS + DX 
                    YPOS' = YPOS + DY

Line drawing

Line drawing will cause a line of some form to be drawn between the current position and another position which is defined absolutely or relatively from the current position. The type of representation for displaying the line will depend on parameters so far unspecified,

As well as drawing the line, the current position is updated.

      TOXY (X, Y)
      Draws a line from the point (XPOS, YPOS) to (X, Y) 
      The current position is reset to: XPOS' = X 
                                        YPOS' = Y

      TODXY (DX, DY)
      Draws a line from the point (XPOS, YPOS) to (XPOS+DX, YPOS+DY) 
      The current position is reset to:  XPOS' = XPOS + DX 
                                         YPOS' = YPOS + DY

There is no real difference, both are different ways of representing an absolute move.

An extension to the line drawing primitives might be the functions:

      PRXY (X, Y) 
      PRDXY (DX, DY)

These routines are similar to TOXY and TODXY except that the current position is not changed. The main reason for suggesting these as primitives is to save operations for functions such as graticule production which are often produced by:

      UPXY (X, Y) 
      TOXY (X, Y') 
      UPXY (X+DX, Y) 
      TOXY (X+DX, Y')
      etc.

This could now be produced as:

      UPXY(X, Y) 
      PRXY (X, Y') 
      UPDXY (DX, 0) 
      TODXY (0, Y'-Y)

It may be possible to suppress the zero parameter to the procedure UPDXY in picture storage or data transmission.

If these primitives were included, the equivalent text string should also be included.

Symbol plotting

We define a set of primitive symbols called Marks. The only coordinate {rather than morphological) attributes of a Mark is that it has a position. It is a means of indicating a particular point in the current coordinate system.

It will normally be expected that a set of Marks are available and that they resemble the standard set of defined Marks although there is no guarantee that the Marks on a particular system will correspond exactly to Marks on another system.

It should be possible for all Marks to be defined in such a way that the center or position indicated by the Mark is uniquely and obviously defined. The preferred position indicated by the Mark is its centre.

      MARK (N)

The Nth type of Mark is output at the current position. The current position remains unchanged.

There is no assumption that Marks have a well-defined size or orientation at any particular instance.

Windowing of the drawn Mark will be as follows:

  1. If CP is outside the Window, it is assumed that the aim will be to generate no output.
  2. If CP is inside Window, some of the Hark will be displayed. If the Mark is produced by hardware, it is likely that all of the Mark will be drawn and that some of the Mark may be outside the Window.

Text production

Text output falls into two distinct areas. The text being output may have no real picture or display significance other than acting as a prompt or message to the user. Alternatively it may be an intrinsic part of the graphical output - for example, labelling of graphs.

It seems sensible to differentiate between these two types of text. The first type should be generated as efficiently as possible with little concern for its size and shape. The second type is more critical as far as size and placement is concerned.

At any point in time, a character size for both types of text will be defined. Each type of text will have its own character size. The motivation behind this decision is that the user does not want to keep switching character size between the two types of output.

We will not specify how these sizes will be set up except to say that Wp and Wt are the current widths of the characters for Prompt (low quality) and Text (reasonable quality) messages. The width of the character is assumed to include the space between characters.

Throw-away Text

      PROMPT ('ABC')

The character string is output with the lower left hand corner of the first character at the current position. If N characters are output, the current position is reset to:

      CP' = CP + N*Wp (or should it be undefined?)

The following recommendations are made:

  1. This primitive should be used to output messages where the efficiency rather than quality of text is important.
  2. The text should be generated by hardware wherever possible.
  3. To avoid overwriting other parts of the picture, text should remain within the total text box for the character string wherever possible.
  4. The individual characters making up the string are not constrained to their own text box. The characters should be output evenly spaced. Thus on a system with a hardware character generator, size considerably smaller than the currently defined character size, output would be as follows:

    ABCD CP Wp CP'

  5. If several strings of text are to be output and even spacing between individual characters is expected, it is necessary to buffer the text and output it as a single text string.
  6. Scissoring of the text string is almost impossible to implement. If any part of the string is visible, it is possible that all of the text string will be output. Conversely, if some part of the text box is scissored, it is possible that some of the strings will be output.

Medium Quality Text

The major purpose for this type of text is drawing annotation. The text is not an end in itself. As the text is part of the drawing, it is assumed that its centring and overall size will correspond, where possible, with the specified size.

      TEXT (ang, 'ABCD')

The specified string is output at the current position corresponding to the lower left corner of the first letter. Current position is updated to CP' = CP + N*Wt.

      XPOS' = N*Wt*Cos(ang) + XPOS 
      YPOS' = N*Wt*Sin(ang) + YPOS

The following recommendations are made:

  1. Text is output by software unless the hardware is capable of generating the right results. However, if software drawing may cause problems as far as space and time is concerned, it is possible that characters are generated by hardware.
  2. Individual characters should reside within their own character boxes. Thus, if the hardware generator is unable to produce characters of the right size and it is required to use it for efficiency purposes, output should be as follows:

    A B C D E CP Wt CP'

  3. Concatenation of subsequent text should give evenly spaced results.
  4. A character should be visible if its individual character box is not clipped. If the box is completely outside the window, the character should not be drawn. If part of the character box is within the window, the result is undefined.

Transformations

There is a single rotation for all drawings. Changes of scale, translation, rotation etc. will affect the size and position of the character boxes for both throw-away and medium-quality text.

For example:

CP W W W

The format of the text will obey the general rules outline in the previous section.

The actual form of the characters is different for the two types of text:

CP CP' ABCD PROMPT('ABCD') A B C D CP CP' TEXT('ABCD')

Attributes

It has been suggested that a number of attributes should be proposed for output primitives.

Some general principles are agreed:

  1. A particular attribute, once set, applies to all line drawing, marking, and text production if possible.
  2. There may be a set of attributes which apply only to line drawing and a second set which apply to line and/or medium quality text.
  3. It should not be assumed that any attributes apply to markers or prompt text.

Some comments:

  1. For most current attributes, there is no clear differentiation between one and another.
  2. It is impossible to split the two attributes of colour and intensity. Frequently colour is defined as a number of beams being passed through a set of filters at a specified set of intensities. Thus it is impossible to change intensity without changing colour. A full description and specification of colour/intensity applicable to video tubes, colour filter systems and ink jet plotters is a large research topic.
  3. Line thickness is likely to affect both colour and intensity. Thus thickness is not an orthogonal attribute.
  4. Broken lines may be separated out as a different attribute. However, their definition is so application dependent that it is not sensible to define it at this time.

Recommendations:

      ATTRB (I)

Sets attribute for future output to type I. No specification for individual I's are given other than I=0, say, is the default setting of solid, normal intensity, uncoloured, single thickness lines.

Other I values should be specified by the user. Portability is defined by the originator giving the new user a specification of what he had in mind for each I.

There is no guarantee that the output will be identical on both systems. Different I values should, where possible, be differentiable by the viewer.

⇑ 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