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

Design Criteria

T.L. Sancha

  1. The standard is not concerned with portability of the software itself but rather with a definition of hardware and system independent interfaces.
  2. The interface should be designed in such a way as to minimize the effort of writing the machine and device dependent parts of the system while at the same time maximising the power of the software which uses it.
  3. The standard should state which functions must be implemented, which are optional, which are reserved for extensions and which are available for local use.
  4. A hierarchy of functions which may be used to simulate unavailable functions should be defined.
  5. As few concepts as possible should be involved, but any concept allowed should be allowed in all its manifestations (i.e. the concepts should be as orthogonal as possible). Similar capabilities should be controlled in the same way.
  6. For clarity and generality the interface should be defined as a data protocol rather than as a subroutine protocol.
  7. Few assumptions can be made about the arithmetic capabilities and data formats. However, it may be assumed that integers have at least 12 bits and that real numbers have a mantissa of at least 24 bits, of which one bit will be the sign bit, and an 8 bit exponent to base 2. The characters should be held in integers using the ISO/ASCII character code. It may be useful to define formatting and positioning characters (e.g. half space along or up).
  8. No assumptions about the host computers run-time system can be made. Thus, for example, it is not possible to intercept FORTRAN formatted I/O etc. dispatch to the display. This must all be done via routine calls.
  9. No satisfactory general purpose data structure has yet been developed, nor is there any necessary connection between graphics and data structures. Therefore the minimum possible structuring, consistent with practical use, should be catered for.
  10. The standard, while being simple, must cater for a wide range of applications.
⇑ 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