A HIGH-LEVEL GRAPHICS LANGUAGE BASED ON THE GRAPHICAL KERNEL SYSTEM by HANQIU SUN B.A.Sc, Huazhong U n i v e r s i t y , 1981 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES Department of E l e c t r i c a l E n g i n e e r i n g We accept t h i s t h e s i s as conforming to the r e q u i r e d standard THE UNIVERSITY OF BRITISH COLUMBIA February 1986 © Hanqiu Sun, 1986 In p r e s e n t i n g t h i s t h e s i s i n p a r t i a l f u l f i l m e n t of the requirements f o r an advanced degree at the U n i v e r s i t y o f B r i t i s h Columbia, I agree t h a t the L i b r a r y s h a l l make i t f r e e l y a v a i l a b l e f o r r e f e r e n c e and study. I f u r t h e r agree t h a t p e r m i s s i o n f o r e x t e n s i v e copying of t h i s t h e s i s f o r s c h o l a r l y purposes may be granted by the head o f my department or by h i s or her r e p r e s e n t a t i v e s . I t i s understood t h a t copying o r p u b l i c a t i o n o f t h i s t h e s i s f o r f i n a n c i a l g a i n s h a l l not be allowed without my w r i t t e n p e r m i s s i o n . Department of Fkcf^''ccv£ (p^r'KA*-'r/o , fIBf >E-6 (3/81) i i A b s t r a c t Being an a p p l i c a t i o n area of programming languages, g r a p h i c s languages should keep pace with the development of today's programming languages. Data types, s t r u c t u r a l o p e r a t i o n s and f r e e layout of statements p r o v i d e a more e f f e c t i v e means of p i c t u r e g e n e r a t i o n , i . e . , mod e l l i n g , r e n d e r i n g and viewing. The G r a p h i c a l Kernel System (GKS), an i n t e r n a t i o n a l standard g r a p h i c s language s i n c e 1984, i s s p e c i f i e d on a subroutine b a s i s , t h e r e f o r e s u f f e r i n g from the la c k of such h i g h - l e v e l language f e a t u r e s . T h i s t h e s i s i n v e s t i g a t e s and implements the FORTRAN language b i n d i n g of GKS i n t o a h i g h - l e v e l programming language (HL/GKS) by a generated pre c o m p i l e r . The weaknesses and r e s t r i c t i o n s of GKS and i t s FORTRAN b i n d i n g are d i s c u s s e d . The advanced f e a t u r e s and f u n c t i o n s of HL/GKS are addressed. The g r a p h i c a l syntax and semantics r u l e s of the extended p o r t i o n of HL/GKS are in t r o d u c e d . I t i s expected t h a t HL/GKS w i l l have more a t t r a c t i v e f e a t u r e s and e f f e c t i v e p r o d u c t i v i t y f o r GKS a p p l i c a t i o n s compared to the p r o c e d u r e - l e v e l GKS system. The input statements of HL/GKS have the c a p a b i l i t y of p i c t u r e communication by i n t e r a c t i v e d e v i c e s and hence enable the implementation of s o p h i s t i c a t e d g r a p h i c a l a p p l i c a t i o n programs. i i i Table of Contents A b s t r a c t i i L i s t of F i g u r e s i v Acknowledgement v Chapter I INTRODUCTION 1 Chapter II A SURVEY OF HIGH-LEVEL GRAPHICAL LANGUAGES 8 2.1 CADEP (1971) 12 2.2 GPL/I (1971) 14 2.3 GRAPHEX68 ( 1975) 16 2.4 MIRA ( 1981 ) 17 2.5 LIG (1982) 19 2.6 PASCAL/GRAPH (1982) 20 Chapter III THE GRAPHICAL KERNEL SYSTEM 23 3 . 1 Overview . 23 3.2 E v a l u a t i o n of GKS 27 3.2.1 Poor Syntax D e f i n i t i o n 28 3.2.2 R e s t r i c t e d Semantics Performance 28 3.2.3 Ambiguous A t t i b u t e S e t t i n g s 30 Chapter IV STUDIES ON THE HIGH-LEVEL GKS LANGUAGE (HL/GKS) 33 4.1 O b j e c t i v e s 33 4.2 G r a p h i c a l Types and S t r u c t u r e s 36 4.3 HL/GKS Implementation 43 4.3.1 L e x i c a l Usage 47 4.3.2 Syntax Rules 49 4.3.3 Semantics Rules 56 Chapter V EXAMPLES OF GKS AND HL/GKS LANGUAGE PROGRAMS 60 Chapter VI CONCLUSION AND PROPOSALS 85 REFERENCES 91 BIBLIOGRAPHY 92 APPENDIX A - SYNTAX IN BACKUS-NAUR FORM 95 APPENDIX B - RESERVED WORDS AND SYMBOLS 100 APPENDIX C - EXECUTION INSTRUCTIONS 101 APPENDIX D - A SAMPLE OF GKS OBJECT CODE 103 i v L i s t of F i g u r e s 1. Two Models i n Language Communications 1 2. A Piece of Code of the Language GLIDE(77) 3 3. Comparison of Subroutine Packages and High-Level Languages 4 4. Data Type E l l i p s e i n the Language MIRA 5 5. Blocks S t r u c t u r e of the Language IMAGE 8 6. Basic E x p r e s s i o n s i n the Language ESP 3 9 7. H i e r a r c h i c a l D e f i n i t i o n of the Language GLIDE 9 8. Computation Expre s s i o n s i n the Language MUMBLE 10 9. Data Types and Operators of Language GRAPHEX68 16 10. R e l a t i o n s h i p of the GKS Spaces 24 11. The Routine f o r E v a l u a t i n g Transformations of GKS ....25 12. Legal T r a n s i t i o n of the GKS S t a t e s 26 13. The Segment Functions i n GKS 28 14. S u p e r p o s i t i o n Operation i n GKS 29 15. T o p o l o g i c a l View of GKS A t t r i b u t e s 30 16. The Colour A t t r i b u t e s of GKS 31 17. The Text Alignments of GKS . •. 31 18. The L e v e l s of Software Support i n G r a p h i c a l Languages 33 19. A Segment D i s p l a y i n GKS 34 20. The T o p l o g i c View of Text A t t r i b u t e 35 21. Name and Number S e t t i n g of P o l y l i n e A t t r i b u t e s 35 22. Some G r a p h i c a l E x p r e s s i o n s of HL/GKS 37 23. Vector Assignments of HL/GKS 38 24. The Vector Operators 38 25. Vector Placements i n HL/GKS 38 26. Segment Operations i n HL/GKS Environments 39 27. The A l t e r n a t e S e t t i n g s of Two Transformations 40 28. A D i s p l a y Fragment in GKS and HL/GKS Language 42 29. The I n t e r f a c e of the Precompiler of HL/GKS to the CWS-TD System 43 30. The Transformation Steps of the HL/GKS Language 43 31. The S t r u c t u r e s of the Data Models 44 32. The G r a p h i c a l Layout of HL/GKS 47 33. S y n t a c t i c a l E x p r e s s i o n of New S t r u c t u r e s ' 48 34. The O u t l i n e s of the St a t e s i n Both Languages 49 35. The Major Components of the GKS System 51 36. Output Examples of HL/GKS 51 37,. A l t e r n a t i v e S e t t i n g s of A t t r i b u t e s 52 38. M u l t i p l e Output of the P r i m i t i v e P o l y l i n e 53 39. The Data Types f o r the Logic Devices 54 40. M u l t i p l e Output D i s p l a y Statements of HL/GKS 55 41. M u l t i p l e Output i n HL/GKS and GKS 55 42. Some Assignment Instances of HL/GKS 56 43. The Semantics of Symbols and Operators of HL/GKS 57 44. Read Statements of HL/GKS 59 45. Some I n t e r p o s i n g Instances i n HL/GKS 85 46. An A r b i t r a r i l y Ordered Segment Tansformation i n Both Languages ' 86 47. Segment M o d e l l i n g i n HL/GKS 87 v i Acknowledgement I am most g r a t e f u l to my parents, members of my f a m i l y and a l l my dear f r i e n d s f o r t h e i r contant encouragement. I would l i k e to express my s i n c e r e a p p r e c i a t i o n to Dr. G.F. Schrack, the s u p e r v i s o r of t h i s p r o j e c t , f o r h i s continued i n t e r e s t , encouragement and guidance d u r i n g the r e s e a r c h work and w r i t i n g of the t h e s i s . T h i s r e s e a r c h would not have been p o s s i b l e were i t not f o r the f i n a n c i a l support of the People's Republic of China. 1 I. INTRODUCTION As a communications c a r r i e r between computers and human beings, a computer language takes the r e s p o n s i b i l i t y of c o n f e r r i n g a user's i n t e n t i o n expressed i n the language to the computer, and of r e p o r t i n g r e l a t e d r e s u l t s processed by the computer back to the user. In order to communicate n a t u r a l l y and f r e e l y , the implementation of h i g h - l e v e l . programming languages has been i n v e s t i g a t e d through many y e a r s . The language FORTRAN i s c h a r a c t e r i z e d by i t s n a t u r a l a r i t h m e t i c e x p r e s s i o n s , the language PASCAL o r i g i n a t e d from a need to d e f i n e data s t r u c t u r e s f l e x i b l y , and LISP i s based on i t s a t t r a c t i v e f e a t u r e s of l o g i c a l r e l a t i o n s h i p s . B a s i c a l l y , a l l h i g h - l e v e l programming languages emphasize the d i f f e r e n c e s of a c t u a l and a b s t r a c t , r e a l i s t i c and v i r t u a l models d u r i n g the communication p r o c e s s . The i n t e r r e l a t i o n s h i p between two models i s shown i n F i g u r e 1 . i A b s t r a c t f ! Model * Actual Model F i g u r e 1 - Two Models i n Language Communications When f o l l o w i n g the development of programming languages, beginning from machine codes, to assembly languages, and to today's programming languages, h i g h - l e v e l languages tend to 2 o f f e r more freedom to users so that a programmer i s able to c o n c e n t r a t e f u l l y on r e s e a r c h problems rather than on system d e t a i l s . To meet t h i s requirement, data types, v a r i a b l e s , block s t r u c t u r e s , and c o n t r o l f a c i l i t i e s have formed a necessary part of h i g h - l e v e l programming languages. In f a c t , transparency to the r e a l world and c l o s e n e s s to a n a t u r a l language became the major c h a r a c t e r i s t i c s of a h i g h — l e v e l programming language. Graphics languages can be c o n s i d e r e d as an a p p l i c a t i o n area of programming languages. Three a s p e c t s of computer gr a p h i c s need to be d e a l t with i n languages, namely, p i c t u r e m o d e l l i n g , p i c t u r e r e n d e r i n g , p i c t u r e v i e w i n g . A p i c t u r e i s modelled by p i c t u r e elements, rendered through data p r o c e s s i n g , and viewed on d i f f e r e n t g r a p h i c a l d e v i c e s . In a g r a p h i c s language, p i c t u r e m o d e l l i n g and viewing are a f f e c t e d by programming f u n c t i o n s and i n t e r a c t i v e f a c i l i t i e s ; p i c t u r e r e n d e r i n g i s mainly processed on the b a s i s of a b u i l t - i n database and data s t r u c t u r e s . S i m i l a r to h i g h - l e v e l programming languages, g r a p h i c a l types and h i e r a r c h i c a l p i c t u r e s t r u c t u r e s should be i n c l u d e d i n a h i g h - l e v e l g r a p h i c s language. Regarding the h i e r a r c h i c a l s t r u c t u r e of g r a p h i c a l o b j e c t s , two kinds of element r e f e r e n c e s are d i s t i n g u i s h e d : s i n g l e l e v e l r e f e r e n c e , m u l t i p l e l e v e l r e f e r e n c e . S i n g l e l e v e l r e f e r e n c e means th a t only a s i n g l e g r a p h i c a l o b j e c t , composed of a c o l l e c t i o n of one or more gra p h i c s 3 p r i m i t i v e s , can be r e f e r e n c e d ; m u l t i p l e l e v e l r e f e r e n c e means that subelements, at v a r i o u s l e v e l s of an o b j e c t s t r u c t u r e d t r e e , can be accessed. S u p e r p o s i t i o n and d e l e t i o n are the two g r a p h i c a l o p e r a t i o n s to deal with h i e r a r c h i c a l s t r u c t u r e s . A g r a p h i c a l o b j e c t can be c o n s t r u c t e d by superposing i t s subparts l e v e l by l e v e l and by d e l e t i n g some of i t s subparts at c e r t a i n l e v e l s . Other p r o c e s s i n g f u n c t i o n s , such as replacment, zooming, e t c . , can be simulated with those two f u n c t i o n s . T h e r e f o r e , an e v a l u a t i o n of a g r a p h i c s language u s u a l l y focuses on the data s t r u c t u r e s and b a s i c f u n c t i o n s of the language p r o v i d e d . During the r e s e a r c h process of h i g h - l e v e l g r a p h i c s languages, two main approaches have emerged: e n t i r e l y new g r a p h i c s language, g r a p h i c s extension on a standard language. A new g r a p h i c s language o f f e r s f u l l freedom i n p r o v i d i n g g r a p h i c a l t o o l s f o r programmers. A p i c t u r e grammar, comprehensive modelling, and v e r s a t i l e f a c i l i t i e s are p r o v i d e d v i a the language d e f i n i t i o n . However, t h i s approach has not been p o p u l a r l y adopted except f o r some s p e c i a l c a ses. The reason i s that a more or l e s s e x t e n s i v e compiler needs to be developed and that p r o v i d i n g the necessary n o n - g r a p h i c a l computing support i s d i f f i c u l t . The language GLIDE(77)[East77] i s designed w i t h i n t h i s c l a s s . An example of i t s code i s demonstrated i n F i g u r e 2. The second c l a s s , language exte n s i o n s , has f u r t h e r d i v e r g e d i n t o two subbranches: 4 ATTRIB TEXT t i t l e , notes; ATTRIB REAL s h e l f l e n g t h , d e s k f t , f i l e s p a c e ; ATTRIB BOOL phone; FORM WORKSPACE = BFORM t i t l e < — ' s e c r e t a r y ' ; s h e l f l e n g t h <-- 15; d e s k f t < — 5; phone <-- t r u e ; notes < — 'none' EFORM; COPY WORKSPACE[10] = {; phone <-- f a l s e } ; COPY WORKSPACE = {; t i t l e < — ' c h a i r m a n ' ; d e s k f t < — 1 0 ; n o t e s < — ' l i k e s red wallpaper'}; F i g u r e 2 - A Piece of Code of the Language GLIDE(77) subroutine packages, extended languages. Both of these i n c o r p o r a t e g r a p h i c s c o n s t r u c t i o n s i n t o a host language but by d i f f e r e n t approaches. In subroutine packages, some g r a p h i c a l s u b r o u t i n e s are simply added to the ho s t ' s runtime l i b r a r y , thus no a d d i t i o n a l c o m p i l a t i o n i s r e q u i r e d f o r i t s implementation. The system i s e a s i l y extendable and p o r t a b l e to serve d i f f e r e n t needs and i n s t a l l a t i o n s . T h e r e f o r e , subroutine packages are adopted as a common design approach i n p r a c t i c e . On the other hand, sub r o u t i n e packages are not the proper c a n d i d a t e s f o r h i g h — l e v e l g r a p h i c s languages because of the shortage of data types and s t r u c t u r e s . The f u n c t i o n s of p i c t u r e m o d e l l i n g , r e n d e r i n g and viewing are processed o n l y by subroutine c a l l s v i a parameter l i s t s . For a l a r g e system with many sub r o u t i n e s and even more parameters, programming becomes d i f f i c u l t . A l s o , most programming e r r o r s can only be d e t e c t e d at e xecution time, thus l e a d i n g to a l o s s of i t s appeal as a language. A comparison between sub r o u t i n e packages and h i g h - l e v e l g r a p h i c s languages i s presented i n F i g u r e 3. 5 Subroutine Packages High-Level Languages numerical c o o r d i n a t e s g r a p h i c a l v a r i a b l e s a r r a y s of c o o r d i n a t e s s t r u c t u r e d g r a p h i c a l v a r i a b l e s input and output c a l l s i n t e r a c t i v e statements f u n c t i o n s c a l l s g r a p h i c a l keywords and symbols a t t r i b u t e s c a l l s name assignments c o n t r o l s c a l l s syntax p a r s i n g F i g u r e 3 - Comparison of Subroutine Packages and High-L e v e l Languages Consequently, no d i s t i n c t i o n i s made between g r a p h i c a l p r o c e s s i n g and c o n v e n t i o n a l p r o c e s s i n g i n the form of subroutine c a l l s , r e s u l t i n g i n a l a c k of e x p l i c i t n e s s of the syntax and the semantics of the language. Extended languages; i n c o n t r a s t , i n c l u d e g r a p h i c a l data types and ope r a t o r s in t h e i r extended p o r t i o n . F r e q u e n t l y r e f e r r e d - t o p i c t u r e elements can be d e f i n e d f o r m a l l y as standard data types of a language; commonly used p i c t u r e o p e r a t o r s can be expressed s y m b o l i c a l l y as res e r v e d words i n i t s syntax. As an example, the g r a p h i c a l data type e l l i p s e i n the language MIRA[Magn8l] i s presented i n F i g u r e 4. TYPE e l l i p s e = FIGURE ( c e n t r e : v e c t o r ; a,b: r e a l ) ; VAR t h e t a , s t e p : r e a l ; x1,x2: v e c t o r ; BEGIN theta := 0.0; x1 := « a , 0 . 0 > > + c e n t r e ; step:= 0.1; WHILE t h e t a <= 2.0*pi DO BEGIN t h e t a := t h e t a + step; x2 := <> + c e n t r e ; CONNECT(x1,x2); x1 := x2 END END; F i g u r e 4 - Data Type E l l i p s e i n the Language MIRA Another example i s the union operator U, appearing i n the language GRAPHEX68[Dene75] as: 6 menu <-- and SCAL 0.25 POS (0.8,0.8) U or SCAL 0.25 POS (0.8,0.6) Obvio u s l y , an extended language shows many a t t r a c t i v e p o i n t s due to i t s g r a p h i c a l types, p i c t u r e s t r u c t u r e s , and symbolic e x p r e s s i o n s . These are implemented at the expense of e f f o r t s i n precompiler c o n s t r u c t i o n or compiler e x t e n s i o n . From the a n a l y s i s above, subroutine packages are a p p r o p r i a t e f o r ge n e r a t i v e (of v e r t i c e s and p a t t e r n s ) g r a p h i c s i n p i c t u r e viewing; and an extended language i s more s u i t a b l e f o r i n f e r e n t i a l ( r e l a t i o n a l d e s c r i p t i o n ) g r a p h i c s i n p i c t u r e m o d e l l i n g and r e n d e r i n g . The G r a p h i c a l Kernel System (GKS)[Ende84], recommended as an i n t e r n a t i o n a l g r a p h i c s standard s i n c e 1984, i s s p e c i f i e d on the subroutine b a s i s . Obviously, a l l the shortcomings of subroutine * packages w i l l i n f l u e n c e the u t i l i z a t i o n and p o p u l a r i z a t i o n of the GKS system. To f u r t h e r b e t t e r programming using GKS, t h i s t h e s i s i n v e s t i g a t e s the design and implementation the h i g h - l e v e l GKS language (HL/GKS) by a b u i l t -i n p r e p r o c e s s o r . Besides removing the r e s t r i c t i o n s of subroutine c a l l s , HL/GKS has hidden many d e t a i l s of the GKS s p e c i f i c a t i o n , s i m p l i f i e d the performance of GKS f u n c t i o n s and int r o d u c e d new g r a p h i c a l types and op e r a t o r s while s t a y i n g compatible with the concepts of GKS. HL/GKS i s implemented as a FORTRAN exte n s i o n f o r the FORTRAN language b i n d i n g of the GKS standard. The b u i l t - i n p r e p r o c e s s o r , which t r a n s l a t e s HL/GKS programs i n t o GKS subroutine i n v o c a t i o n s , i s s y n t h e s i z e d by means of the Top-Down 7 Compiler W r i t i n g System (CWS)[Schr82]. D e t a i l s of the preprocessor design and gen e r a t i o n w i l l be presented in Chapter 4. Chapter 2 i n t r o d u c e s s e v e r a l a n c e s t o r s of h i g h - l e v e l g r a p h i c s languages i n the extended c l a s s . Advanced g r a p h i c s f e a t u r e s and i n d i v i d u a l design s t y l e s are explo r e d i n some depth. A b r i e f overview and a n a l y s i s of GKS and i t s FORTRAN b i n d i n g i s presented i n Chapter 3. The system o r g a n i z a t i o n and s p e c i f i c a t i o n are d i s c u s s e d . Some of the r e s t r i c t i o n s and weaknesses of GKS and i t s FORTRAN b i n d i n g are po i n t e d out. Chapter 4 d e s c r i b e s the design p r i n c i p l e s and implementation steps of the HL/GKS language. The design o b j e c t i v e s , the new g r a p h i c a l types and s t r u c t u r e s are addressed. The i n t e r n a l data s t r u c t u r e s and r e l a t e d i s s u e s of the preprocessor are i l l u s t r a t e d . Four examples of HL/GKS with each output p i c t u r e are pro v i d e d i n Chapter 5. Example 1 and Example 2 are w r i t t e n i n both HL/GKS and GKS to o f f e r a d i r e c t comparison of the two languages f o r i d e n t i c a l p i c t u r e g e n e r a t i o n . Example 3 and Example 4 are HL/GKS programs that p r o v i d e a d d i t i o n a l programming s t y l e s and a p p l i c a t i o n i n s t a n c e s of the HL/GKS language. More f a c i l i t a t e f e a t u r e s and p r a c t i c a l implementation of HL/GKS can be i n f e r r e d from those examples. 8 I I . A SURVEY OF HIGH-LEVEL GRAPHICAL LANGUAGES Coming from d i f f e r e n t a p p l i c a t i o n areas and p r a c t i c a l i n s t a l l a t i o n environments, a number of h i g h - l e v e l g r a p h i c a l languages have been proposed and implemented i n the past with d i f f e r e n t s t y l e s . For example, the language IMAGE[Brie75], designed i n 1975, concatenates on an OBJECT/ACTION c o n t r o l s t r u c t u r e , the d i s p l a y p i c t u r e d e s c r i p t i o n syntax and the hardware independent h a n d l i n g of input d e v i c e s . An a p p l i c a t i o n program w r i t t e n i n IMAGE i s f u n c t i o n a l l y c o n s t r u c t e d by four independent b l o c k s , as f o l l o w s , ( F i g u r e 5). ENTRY . f i r s t block- f o r i n i t i a l i z a t i o n | O B J E C T d e f i n i t i o n o f g r a p h i c a l o b j e c t s A C T I O N d i s p l a y o b j e c t s by i d e n t i f i c a t i o n PROCEDURE 1 l o c a l s u b r o u t i n e c a p a b i l i t y F i g u r e 5 - Blocks S t r u c t u r e of the Language IMAGE 9 Departing from c o n v e n t i o n a l s e r i a l programming, the language IMAGE shows up as an a c t i o n - o r i e n t e d language. ESP 3 (Extended SNOBOL P i c t u r e P a t t e r n Processor)[Shap75], a l s o designed i n 1976, has a d i f f e r e n t o r i e n t a t i o n . The language i s based on the premise that s t r u c t u r a l d e s c r i p t i o n s are an e s s e n t i a l p a r t of both p i c t u r e c o n s t r u c t i o n and p a t t e r n r e c o g n i t i o n . Basic p i c t u r e e x p r e s s i o n s i n ESP 3 appear in statements as i l l u s t r a t e d i n F i g u r e 6. t = d r a w ( ' l i n e ' , ' s t a r t = ( 1 , 2 ) ; end=(1.5,3);') t1 = t r a n s p i c ( T , ' p o i n t ( T , " T C " ) ==> (1.5,1)') t2 = t u r n p i c ( T , ' a b o u t = p o i n t ( T , " T C " ) ; deg=l80;') F i g u r e 6 - Basic E x p r e s s i o n s i n the Language ESP 3 O r i g i n a t i n g from a l i n g u i s t i c approach, ESP 3 has been s u c c e s s f u l l y implemented f o r the f i e l d of p a t t e r n r e c o g n i t i o n with most of i t s f e a t u r e s being of the nature of a h i g h - l e v e l g r a p h i c s language. GLIDE ( G r a p h i c a l Language f o r I n t e r a c t i v e D e s i g n ) [ E a s t 7 7 ] , proposed in 1977, e x h i b i t s some new design c h a r a c t e r i s t i c s . I t attempts to organize commonly-needed database f e a t u r e s and o p e r a t i o n s f o r the design of p h y s i c a l systems i n a h i g h - l e v e l computing environment. The h i e r a r c h i c a l d e f i n i t i o n of an g r a p h i c a l o b j e c t i n GLIDE i s shown i n F i g u r e 7. Based on a t h r e e - d i m e n s i o n a l o b j e c t database, GLIDE p r o v i d e s an e f f e c t i v e means of s p a t i a l m o d e l l i n g and m a n i p u l a t i o n s f o r a p p l i c a t i o n programs i n CAD. MUMBLE[Guib82], b u i l t i n 1982, i s another g r a p h i c s language a p p r o p r i a t e f o r d e s c r i b i n g bitmaps and d i g i t a l computations f o r 10 E u l e r Operators ""TOPOLOGY s Vertex Coordinates SHAPE PROCEDURE Parameters * POLYHEDRON Shape Operators A t t r i b u t e I n i t i a l i z a t i o n s FORM L o c a t i o n and Copy ^ A t t r i b u t e s COPY F i g u r e 7 - H i e r a r c h i c a l D e f i n i t i o n of the Language GLIDE r a s t e r d i s p l a y s . Boolean o p e r a t i o n s l i k e AND, OR and XOR are performed f o r each p i x e l of the image plane on a b i t - b y - b i t b a s i s . An example of the computations i n MUMBLE i s shown i n Fi g u r e 8. A <- B OR (((B SHIFT[0,1]) + (B SHIFTf0,-1]) + (B SHIFT[1,0]) + (B SHIFT[-1,0]))> ALL 2 ) Fi g u r e 8 - Computation E x p r e s s i o n s i n the Language MUMBLE Moreover, p r i m i t i v e s and geometric o p e r a t i o n s are p r e c i s e l y s p e c i f i e d i n the language MUMBLE. As r a s t e r d e v i c e s are becoming i n c r e a s i n g l y important, the i n t e r e s t i n g and u s e f u l f e a t u r e s of MUMBLE w i l l become apparent due to i t s s p e c i f i c d e s i g n . From the above b r i e f overview, i t becomes obvious t h a t , u n l i k e other uniform programming languages, g r a p h i c s languages 11 have been c r e a t e d of h i g h l y i n d i v i d u a l c h a r a c t e r and v e r s a t i l e s t y l e s stemming from d i f f e r e n t m o t i v a t i o n s , f a c i l i t i e s and p r a c t i c a l requirements. However, what are the common c r i t e r i a f o r every h i g h - l e v e l g r a p h i c s language to f o l l o w ? What are the b a s i c p r i n c i p l e s and c r u c i a l f a c t o r s to be kept i n languages design? In p r a c t i c e , as mentioned before, the three main r e s e a r c h approaches e x i s t i n g i n g r a p h i c s language design a re: subroutine packages, e n t i r e l y new gr a p h i c s languages, extended languages. Subroutine packages are e a s i l y p o r t a b l e and extendable but s t r u c t u r e l e s s ; e n t i r e l y new languages have the freedom of a t o t a l l y new gr a p h i c s syntax and semantics but at the co s t of an e n t i r e l y new compiler i n v o l v e d . T h e r e f o r e , the approach of extended languages has a t t r a c t e d most research a t t e n t i o n due to economics c o n s i d e r a t i o n s . The host language can provide a l l non-graphic computation and c o n t r o l f a c i l i t i e s , thus the co s t of a language implementation i s r e s t r i c t e d to i t s extended g r a p h i c s p a r t . Using the same p r i n c i p l e s of a h i g h - l e v e l programming language d e s i g n , a gra p h i c s language should c o n t a i n i t s g r a p h i c a l types, v a r i a b l e s , and o p e r a t o r s v i a name r e f e r e n c e and h i e r a r c h i c a l s t r u c t u r i n g towards a high e r l e v e l . Three kinds of s t r u c t u r e s are g e n e r a l l y c o n s i d e r e d i n the design of g r a p h i c a l languages: data s t r u c t u r e s , p i c t u r e s t r u c t u r e s , 1 2 language s t r u c t u r e s . Data s t r u c t u r e s deal with the i n t e r n a l r e p r e s e n t a t i o n of g r a p h i c a l o b j e c t s i n the data base; p i c t u r e s t r u c t u r e s focus on the i n t e r r e l a t i o n s h i p s between g r a p h i c a l o b j e c t s i n a p i c t u r e space; and language s t r u c t u r e s c o n s i d e r both i n t e r n a l procedures of system f u n c t i o n s and e x t e r n a l procedures of statement types. In some sense, the p i c t u r e s t r u c t u r e s w i l l somehow be r e f l e c t e d by the i n t e r n a l data s t r u c t u r e s . Data s t r u c t u r e s and language s t r u c t u r e s are mainly concerned with the s t r u c t u r e s of database and language l a y o u t . In the f o l l o w i n g s e c t i o n , some t y p i c a l examples of extended languages are i n v e s t i g a t e d i n some depth, c o n c e n t r a t i n g on the aspe c t s of g r a p h i c s syntax, semantics, and the c r e a t i o n of h i g h -l e v e l language f e a t u r e s such as g r a p h i c a l data types, s t r u c t u r e s , and p i c t u r e o p e r a t i o n s . 2.1 CADEP (1971) (Computer A s s i s t e d D e s c r i p t i o n P a t t e r n s ) CADEP[Brac71] i s a problem-oriented g r a p h i c s language extended i n FORTRAN f o r p o s i t i o n i n g geometric p a t t e r n s i n a two-dimensional space. The g r a p h i c a l types d e f i n e d i n CADEP a r e : geometric, g r a p h i c , u n i l e v e l g r a p h i c , m u l t i l e v e l g r a p h i c . A geometric type i s employed to b u i l d up geometric e n t i t i e s viewed as a u x i l i a r y p a t t e r n s . I t can be as s i g n e d by geometric 13 p r i m i t i v e s and processed by the f o l l o w i n g o p e r a t o r s and funct i o n s . / i n t e r s e c t i o n , + union, - d i f f e r e n c e , * c o n c a t e n a t i o n , . copy(g,s), t r a n s ( g , x l , y 1 , s ) , r o t ( g , x 1 , y 1 , a l f a , s ) . The u n i l e v e l graphic type r e p r e s e n t s p h y s i c a l two-dimensional e n t i t i e s l y i n g on a p a r t i c u l a r g r a p h i c a l plane. An op e r a t i o n and f u n c t i o n used f o r geometric types can be used as a u n i l e v e l type as w e l l . The m u l t i l e v e l graphic type i s composed of s e v e r a l u n i l e v e l p a t t e r n s l y i n g on d i f f e r e n t planes -and belonging to the same p h y s i c a l o b j e c t ( f o r i n s t a n c e , i n i n t e g r a t e d c i r c u i t masks, the same gate l y i n g on d i f f e r e n t l e v e l s ) . The o p e r a t i o n s on m u l t i l e v e l types can be performed on each of the u n i l e v e l types s e p a r a t e l y and then l i n k a l l of them by the con c a t e n a t i o n operator *. In a d d i t i o n , p r e d i c a t e f u n c t i o n s to a c q u i r e the s t a t e and r e l a t i o n s h i p between graphic o b j e c t s as w e l l as d i s p l a y commands are s u p p l i e d i n CADEP. Without i n t e r a c t i v e a c t i v i t i e s i n v o l v e d , CADEP proves to be a p a s s i v e language a p p l i c a b l e to two-dimensional p a t t e r n layout p o s s e s s i n g a simple syntax and n a t u r a l semantics, which l e a d to a w e l l - d e f i n e d language s t r u c t u r e i n CADEP. The i n t r o d u c t i o n of m u l t i l e v e l types p r o v i d e s a c l e a r concept f o r each l e v e l 1 4 model l i n g and thr e e - d i m e n s i o n a l m o d e l l i n g where the same o b j e c t can o v e r l a p d i f f e r e n t l e v e l s . Being an extended FORTRAN language, CADEP keeps a c o n s i s t e n t form i n i t s d e c l a r a t i o n and assignment statements with those of host language FORTRAN. 2.2 GPL/I (1971) (PL/I E x t e n s i o n f o r Computer Graphics) GPL/I[Smit71] i s an i n t e r a c t i v e g r a p h i c s language intended to handle g r a p h i c a l s i t u a t i o n s such as th r e e - d i m e n s i o n a l m o d e l l i n g , hardcopying, d i s p l a y , p i c t u r e storage, c o l o u r a t t r i b u t e s , and p i c t u r e animation. The g r a p h i c a l types i n GPL/I a r e : v e c t o r , image, a t t r , t e x t , g r a p h i c . The o p e r a t i o n s on v e c t o r s are + a d d i t i o n , - d e l e t i o n , *.* dot product, *** c r o s s product; on images are +> i n c l u s i o n , c o n n e c t i o n , p o s i t i o n , s c a l i n g , 1 5 *> r o t a t i o n . Some o p e r a t i o n s and a t t r i b u t e s , such as p e r s p e c t i v e p r o j e c t i o n , i n t e n s i t y , and t h i c k n e s s , are implemented by f u n c t i o n s . G r a p h i c a l types are processed i n t o g r a p h i c a l f i l e s with s e t s of a t t r i b u t e s which can be d i s p l a y e d as an image. F u n c t i o n a l l y , they are c l a s s i f i e d as design f i l e s , d i s p l a y f i l e s , hardcopy f i l e s , s o f t c o p y f i l e s , s torage f i l e s . In GPL/I, g r a p h i c a l a t t r i b u t e s can be as s i g n e d d i r e c t l y to an image or i n d i r e c t l y to an ATTR v a r i a b l e f o r g l o b a l r e f e r e n c e . I n t e r a c t i v e programming i s achieved by extending the standard PL/I i n t e r r u p t management statements. An i n t e r e s t i n g f e a t u r e of the GPL/I system i s i t s animation f u n c t i o n . Both the IMINTR f u n c t i o n and the ANIMATE statement can dynamically process images. With a l l the p r e d e f i n e d d i s p l a y procedures, p i c t u r e viewing i n the GPL/I language i s w e l l performed. The use of c h a r a c t e r s e t s i n s t e a d of names f o r g r a p h i c a l o p e r a t o r s does not convey r e a d i l y t h e i r meaning. A l s o , as most a t t r i b u t e s of v a r i a b l e s are set by f u n c t i o n c a l l s , the GPL/I system r e q u i r e s a l a r g e r runtime l i b r a r y than other systems. 1 6 2.3 GRAPHEX68 (1975) ( G r a p h i c a l Language Features i n ALGOL 68) Depa r t i n g from other languages, GRAPHEX68[Dene75] uses the f a c i l i t i e s of ALGOL 68 f o r d e f i n i n g new g r a p h i c a l data types and o p e r a t o r s . Much f l e x i b i l i t y i s gained thereby which i s v a l u a b l e d u r i n g the experimental d e f i n i t i o n and e v a l u a t i o n phase of the system. The two g r a p h i c a l types i n GRAPHEX68 are p o i n t , p i c t . C o r r e s pondingly, the op e r a t o r s are - connection (of p o i n t s ) , <- assignment, pos, r o t , s e a l , U union (of p i c t u r e s ) , extended by or reduced by. In an a p p l i c a t i o n , g r a p h i c a l types and two v e r s i o n s of the operator connection '-' are d e c l a r e d i n GRAPHEX68 as shown i n Fig u r e 9. mode p o i n t = s t r u c t ( r e a l x,y ) mode s t r i n g = [1:0 f l e x ] char op - = ( p o i n t p1, p o i n t p2 ) r e f p o l y : heap p o l y := ((0 , p 1 ) , ( 1 , p 2 ) ) ; op - = ( r e f po l y pO, p o i n t g ) r e f p o l y : ( i n t n= upb pO; heap[l:n+1 f l e x ] s t r u c t ( i n t beammode, po i n t p) pon; pon[1:n]:= pO; pon[n+l]:= (1,q); pon ) ; Fig u r e 9 - Data Types and Operators of Language GRAPHEX68 17 S e v e r a l procedures are c o n s t r u c t e d f o r h a n d l i n g v a r i o u s i n t e r r u p t s i t u a t i o n s . Being problem o r i e n t e d , GRAPHEX68 d e f i n e s i t s g r a p h i c a l syntax and semantics i n a c o n c i s e and n a t u r a l way. G r a p h i c a l v a r i a b l e s are d e c l a r e d and processed by g r a p h i c a l o p e r a t o r s i n a ra t h e r obvious manner. Moreover, i n t e r a c t i v e f e a t u r e s i n GRAPHEX68 provide a f a c i l e approach on p i c t u r e modelling and viewing. Since no s p e c i f i c s p e c i a l i z e d compiler a c t i v i t i e s are i n v o l v e d , GRAPHEX68 i s completely p o r t a b l e to any system which has an ALGOL 68 compiler i n s t a l l e d . 2.4 MIRA (1981) (A G r a p h i c a l E x t e n t i o n of PASCAL) MIRA[Magn8l] i s a g r a p h i c a l - o r i e n t e d language. I t pr o v i d e s users the means of d e f i n i n g g r a p h i c a l types much l i k e other types of the host language PASCAL. Nested type d e f i n i t i o n s allow s i m u l a t i n g a h i e r a r c h i c a l s t r u c t u r e of g r a p h i c a l o b j e c t s . G r a p h i c a l v a r i a b l e s under each data type are s e m a n t i c a l l y checked to a v o i d any mismatches. The two g r a p h i c a l types d e f i n e d i n MIRA a r e : v e c t o r , f i g u r e . The o p e r a t i o n s on v e c t o r a r e : + a d d i t i o n , * s c a l a r product, read and w r i t e . The o p e r a t i o n s on f i g u r e s are connect, 18 i n c l u d e , c r e a t e , d e l e t e , draw. The c r e a t e statement dynamically c r e a t e s new f i g u r e s i n memory and the d e l e t e statement d e l e t e s them. The draw statement permits a c r e a t e d f i g u r e to be drawn on a g r a p h i c a l t e r m i n a l . F i v e standard f i g u r e types are p r e d e f i n e d i n the system: segment, l i n e , c i r c l e , square, t r i a n g l e . P i c t u r e o p e r a t i o n s such as r o t a t i o n , s c a l i n g and t r a n s l a t i o n are performed by standard procedures i n MIRA. With u s e r - d e f i n e d types and a number of p r e d e f i n e d procedures, the syntax and semantics of MIRA appear q u i t e s t r a i g h t f o r w a r d f o r a naive user who wishes to l e a r n the language. MIRA emphasises p i c t u r e m o d e l l i n g , and pays l e s s a t t e n t i o n to p i c t u r e r e n d e r i n g and viewing. The s u p e r p o s i t i o n o p e r a t i o n i s simulated by nested type s p e c i f i c a t i o n , but the f a c i l i t y of p a r t i a l d e l e t i o n i s m i s s i n g . Consequently no updating i s p o s s i b l e a f t e r an o b j e c t i s b u i l t . The g r a p h i c a l data types and o p e r a t i o n s of MIRA are implemented l i k e a procedure and possess an argument l i s t , an unusual c h a r a c t e r i s t i c , and hence somewhat " i m m a t e r i a l " . 19 2.5 LIG (1982) (Language f o r I n t e r a c t i v e G r a p h i c s , V e r s i o n 6) LIG[Ross82] i s a t h r e e - d i m e n s i o n a l , i n t e r a c t i v e , and o b j e c t - o r i e n t e d language ex t e n s i o n of FORTRAN. In the system, v e r s a t i l e f u n c t i o n s and v i r t u a l models are p r o v i d e d by i t s e x t e n s i v e preprocessor and i n t e r n a l database. The two g r a p h i c a l types d e f i n e d i n LIG are: v e c t o r , g r a p h i c a l . The o p e r a t i o n s on v e c t o r s a r e : + a d d i t i o n , # c r o s s product, || magnitude, / s c a l a r d i v i s i o n , - s u b t r a c t i o n , dot product, * s c a l a r product, .EQ. .NE. v e c t o r comparison. The o p e r a t i o n s on g r a p h i c a l type a r e : + s u p e r p o s i t i o n , d e l e t e statement. F o r m a l l y , four standard g r a p h i c a l p r i m i t i v e s are p r o v i d e d by the runtime l i b r a r y : blank, p o l y l i n e , polygon, t e x t . 20 In a d d i t i o n , LIG i n c l u d e s a programmable p r i m i t i v e model d e f i n i t i o n . P i c t u r e t r a n s f o r m a t i o n s are d e f i n e d s i m i l a r l y to p i c t u r e a t t r i b u t e s . A d d i t i o n a l c o n t r o l s t r u c t u r e s l i k e the case and repeat statements are made a v a i l a b l e . A camera model i s b u i l t i n t o LIG to allow viewing t h r e e - d i m e n s i o n a l o b j e c t s from d i f f e r e n t v i e w p o i n t s . In p a r t i c u l a r , as the preprocessor of LIG parses a l l statements, not only g r a p h i c s statements, f u l l communication between g r a p h i c a l types and non - g r a p h i c a l types i s pro v i d e d . Being a s e l f - s u f f i c i e n t g r a p h i c s system, some incompatible language c o n s t r u c t s appear i n LIG. For example, a r e f e r e n c e p o i n t i s set s e p a r a t e l y from t r a n s f o r m a t i o n s , the d e l e t i o n o p e r a t i o n i s expressed i n statement form r a t h e r than the sy m b o l i c a l one l i k e the s u p e r p o s i t i o n o p e r a t o r . In c o n t r a s t , the data s t r u c t u r e i n LIG i s w e l l d e f i n e d and i s f u l l y a c c e s s i b l e . 2.6 PASCAL/GRAPH (1982) (Extension of PASCAL) PASCAL/GRAPH[Bart82] i s another language extending PASCAL which o f f e r s device-independent programming. A d e v i c e -independent language allows a programmer to focus h i s a t t e n t i o n on the c r e a t i o n of a b s t r a c t models, the use of i n t e l l i g i b l e a l g o r i t h m s , and the c l a r i t y of the r e s u l t s . The data types i n PASCAL/GRAPH a r e : p i c t u r e , o u t u n i t , 21 i n u n i t . Operations on p i c t u r e a r e : over, conn, . app, e n c l . The f u n c t i o n s on each g r a p h i c s device are d i s t i n c t from each i n d i v i d u a l c a l l , such as: readcoord ( d i g i t i z e r , x, y ) , r e a d p i c t u r e ( d i g i t i z e r , p ) , r e a d r e a l ( v a l u a t o r , x ) , readchar (keyboard, c ) . G r a p h i c a l p r i m i t i v e s and o p e r a t i o n s are d e c l a r e d as standard f u n c t i o n s i n PASCAL/GRAPH, p r o v i d i n g a powerful means f o r model b u i l d i n g . In PASCAL/GRAPH, the f u n c t i o n over corresponds to the s u p e r p o s i t i o n o p e r a t i o n ; the d e l e t i o n o p e r a t i o n i s p a r t l y r e a l i z e d by the s u b s t i t u t e f u n c t i o n . The main f e a t u r e of PASCAL/GRAPH appears to be i t s machine independence, accomplished by adapting the system to the a v a i l a b l e g r a p h i c a l hardware using d e s c r i p t i o n t a b l e s . With hardware d e v i c e s mapped to l o g i c d e v i c e s , i t i s p o s s i b l e to w r i t e i n t e r a c t i v e programs f o r a r b i t r a r y g r a p h i c a l device i n s t a l l a t i o n s i n PASCAL/GRAPH. As i n t r o d u c e d above, language extensions f o r g r a p h i c s allow the c r e a t i o n of g r a p h i c a l types and s t r u c t u r e s , and the p r o c e s s i n g of g r a p h i c a l o b j e c t s based on the p r e d e f i n e d g r a p h i c a l syntax and semantics. Procedures and statements are 22 the two a l t e r n a t i v e s y n t a c t i c a l c o n s t r u c t s f o r e x p r e s s i n g g r a p h i c s . Statements r e q u i r e more p r o c e s s i n g e f f o r t by the preprocessor but have a n a t u r a l appearance; procedures i n c r e a s e the s i z e of the runtime l i b r a r y with r e s t r i c t e d c l a r i t y . Both symbolic o p e r a t o r s and i d e n t i f i e r s r e p r e s e n t i n g g r a p h i c a l o p e r a t o r s are adopted i n language design as both are s u i t a b l e f o r d i f f e r e n t s i t u a t i o n s . I n t e r a c t i v e f a c i l i t i e s are c o n s i d e r e d to be an important means i n p i c t u r e m o d e l l i n g e s p e c i a l l y f o r en g i n e e r i n g a p p l i c a t i o n s . In summary, data s t r u c t u r e s and language s t r u c t u r e s are the most important r e s e a r c h areas f o r the implementation of h i g h -l e v e l g r a p h i c s languages. 23 I I I . THE GRAPHICAL KERNEL SYSTEM 3.1 Overview The G r a p h i c a l Kernel System, GKS, has been developed by the I n t e r n a t i o n a l Standards O r g a n i z a t i o n i n a long process s i n c e 1976 and f i n a l l y evolved as the i n t e r n a t i o n a l l y recognized standard i n computer g r a p h i c s i n 1984. GKS belongs to the c l a s s of subroutine packages. With GKS, a programmer can i n c o r p o r a t e g r a p h i c a l tasks w i t h i n an a p p l i c a t i o n program to produce and manipulate p i c t u r e s . The most important f e a t u r e of GKS system i s i t s independence from any p a r t i c u l a r programming language and from any g r a p h i c a l d e v i c e , which makes GKS t o t a l l y t r a n s p o r t a b l e and independent of hardware updations and c o n f i g u r a t i o n s . To r e a l i z e the idea, the concepts of l o g i c input d e v i c e s and f u n c t i o n a l w o r k s t a t i o n s were in t r o d u c e d . There are s i x l o g i c input d e v i c e s d e f i n e d i n GKS: l o c a t o r , v a l u a t o r , c h o i c e , p i c k , s t r i n g , s t r o k e . The concept of workstation t i e s a f l e x i b l e v i r t u a l system to a v a r i e t y of r e a l - w o r l d d e v i c e s . Each workstation c o n s i s t s of a s i n g l e d i s p l a y s u r f a c e with zero or more input d e v i c e s . 24 For i n s t a n c e , a p l o t t e r i s c o n s i d e r e d to be the simplest w o r k s t a t i o n . The data types of GKS are s p e c i f i e d independently of any s p e c i f i c programming language. For i n s t a n c e , the data type enumeration comprises an ordered set of values which can be mapped, e.g., to the s c a l a r type i n the language PASCAL or to the i n t e g e r type i n FORTRAN. Three s e t s of c o o r d i n a t e spaces are a v a i l a b l e i n GKS to f a c i l i t a t e independent t r a n s f o r m a t i o n s of g r a p h i c a l data. They are world c o o r d i n a t e spaces (WC), normalized d e v i c e c o o r d i n a t e space (NDC), device c o o r d i n a t e spaces (DC). WC spaces are the a p p l i c a t i o n spaces to be used by a programmer independently of g r a p h i c a l output d e v i c e s . A DC space i s the co o r d i n a t e space s p e c i f i c to a d i s p l a y d e v i c e . The NDC space i s chosen as the uniform c o o r d i n a t e space of a v i r t u a l d e v i c e , conceived to l i e between the WC spaces and DC spaces. To map the data from one c o o r d i n a t e space to another, two types of system t r a n s f o r m a t i o n s are s p e c i f i e d : n o r m a l i z a t i o n t r a n s f o r m a t i o n s (NT), workstation t r a n s f o r m a t i o n s (WT). The r e l a t i o n s h i p s of the c o o r d i n a t e spaces v i a the t r a n s f o r m a t i o n mappings are i l l u s t r a t e d i n F i g u r e 10. Another main concept i n the GKS system besides workstations i s segments. 25 F i g u r e 10 - R e l a t i o n s h i p of the GKS Spaces GKS system = segments + ; workstations + ... The w o r k s t a t i o n s correspond to the i n t e r f a c e between a GKS program and g r a p h i c a l t e r m i n a l s while segments are the b a s i c o b j e c t s which are e a s i l y r e f e r r e d t o f o r p i c t u r e p r o c e s s i n g . G e n e r a l l y , the syntax of GKS i s represented by the f o l l o w i n g two a s p e c t s . (1) The P r o t o c o l of Subroutine C a l l s There are 201 subrout i n e s s p e c i f i e d i n the FORTRAN language b i n d i n g of GKS. For each su b r o u t i n e c a l l , the parameter order, parameter data types, and the subr o u t i n e name have t o observe s t r i c t r e f e r e n c e r u l e s . For example, to ev a l u a t e a t r a n s f o r m a t i o n matrix i n the FORTRAN b i n d i n g of GKS, the r o u t i n e needing to be invoked are shown i n F i g u r e 11. Any mismatch i n number, order, or data type w i l l cause a f a i l u r e of the performance. 26 GEVTM(xO,yO,dx,dy,phi,fx,fy,sw,mout) where xO,yO(real) r e f e r e n c e p o i n t to the t r a n s f o r m a t i o n s d x , d y ( r e a l ) s h i f t v e c t o r , p h i ( r e a l ) the r o t a t i o n angle, f x , f y ( r e a l ) s c a l e f a c t o r s f o r x and y c o o r d i n a t e s , sw(integer) a parameter i n d i c a t i n g the c o o r d i n a t e space, . 0 world c o o r d i n a t e s , . 1 normalized device c o o r d i n a t e s , mout(real) the name of a 2 by 3 a r r a y which w i l l c o n t a i n the r e s u l t i n g t r a n s f o r m a t i o n ma t r i x. F i g u r e 11 - The Routine f o r E v a l u a t i n g Transformations of GKS (2) GKS St a t e s There are f i v e system s t a t e s d e f i n e d i n GKS: . GKS c l o s e d , GKS open, at l e a s t one workstation open, at l e a s t one work s t a t i o n a c t i v e , at most one segment open. The l e g a l t r a n s i t i o n s of the s t a t e s i s presented i n F i g u r e 12. Under each s t a t e , only c e r t a i n subroutine c a l l s are allowed t o be i s s u e d . For example, the statement " d e a c t i v a t e w o r k s t a t i o n " i s not l e g a l i n the s t a t e "workstation open"; the command "open GKS" i s not ac c e p t a b l e i n the s t a t e "workstation a c t i v e " . The l e g a l set of subroutine i n v o c a t i o n s under each s t a t e shows the proper syntax order of GKS. The semantics of GKS are i m p l i c i t l y passed to each subroutine i n v o c a t i o n . The subroutine of the p r i m i t i v e POLYLINE(n,px,py) i m p l i e s that N p o i n t s are to be connected by l i n e segments as a p o l y l i n e . The c a l l of the p r i m i t i v e 27 CKS closed o p e n C K S close C K S GKS open o p e n f i r s t w o r k s t a t i o n close last w o r k s t a t i o n o p e n •-•st. c l o s e w JT. A t c a s t o n e w o r k s t a t i o n o p e n a c t i v a t e -first w o r k s t a t i o n a c t i v a t e w st. (deactivate » st. •open * st. c / q lose » rt. a t t r i b u t e s e t t i n g i n p u t ; s e g m e n t m a n i p u l a t i o n d e a c t i v a t e l a s t w o r k s t a t i o n A t l e a s t o n e w o r k s t a t i o n a c t i v e o p e n s e g m e nt c lose s e g m e n t Segment open p-rtmltive g e n e r a t i o n -a t t r i b u t e s e t t i n g i n p u t •' / s e g m e n t m a n i p u l a t i o n p r i m i t i v e g e n e r a t i o n a t t r i b u t e s e t t i n g Input-F i g u r e 12 - L e g a l T r a n s i t i o n of the GKS S t a t e s TEXT(px,py,chars) c o n f e r s that a s t r i n g of c h a r a c t e r s i s output, s t a r t i n g at p o i n t (px,py). 3.2 E v a l u a t i o n of GKS A review of GKS w i l l r e v e a l some r e s t r i c t i o n s and inconveniences of the system performance, stemming from i t s own d e f i n i t i o n . 28 3.2.1 Poor Syntax D e f i n i t i o n To use GKS, a programmer needs not only to understand a l l the d e t a i l s of the system s p e c i f i c a t i o n but a l s o to take the r e s p o n s i b i l i t y of c o r r e c t i n v o c a t i o n of su b r o u t i n e s , and s i m i l a r d e t a i l s . When can a segment be opened? Which su b r o u t i n e s can be c a l l e d i n the present s t a t e ? What i s the proper subroutine name and which are the proper parameters which need to be r e f e r r e d to? Which wor k s t a t i o n i s open and a c t i v e ? Taking care of such r e s t r i c t i o n s undoubtly becomes an unnecessary burden. 3.2.2 R e s t r i c t e d Semantics Performance In GKS, segments represent p i c t u r e u n i t s , thus segment o p e r a t i o n s r e f e r to p i c t u r e o p e r a t i o n s . The segment f u n c t i o n s d e f i n e d i n GKS are given i n F i g u r e 13. c r e a t e segment c l o s e segment rename segment d e l e t e segment (from workstation) a s s o c i a t e segment with w o r k s t a t i o n copy segment to work s t a t i o n i n s e r t segment F i g u r e 13 - The Segment Fu n c t i o n s i n GKS The p a i r " c r e a t e segment" and " c l o s e segment" d e a l s with the s t a t e flow of GKS. "Rename segment" r e a s s i g n s a new segment name to a c r e a t e d segment. "Delete", " a s s o c i a t e " and "copy segment" perform the s p e c i f i e d f u n c t i o n s on d i s p l a y w o r k s t a t i o n s . Among these segment o p e r a t i o n s , " i n s e r t segment" i s the only one which simulates the s u p e r p o s i t i o n f u n c t i o n f o r p i c t u r e m o d e l l i n g . As only a s i n g l e l e v e l r e f e r e n c e of segments i s p r o v i d e d , the d e l e t i o n o p e r a t i o n i s not supported by GKS. 29 The absence of t h i s f u n c t i o n may cause t r o u b l e when i t i s r e q u i r e d in an a p p l i c a t i o n . For example, i t i s not p o s s i b l e to have a s i t u a t i o n l i k e : house:- house - window(1) + window(2) For GKS, a programmer needs to r e b u i l d a new segment which c o n t a i n s a l l the o r i g i n a l o b j e c t s i n the segment house with the ex c e p t i o n that segment window(1) i s r e p l a c e d by window(2), then d e l e t e segment house and rename the new segment as house. I n d i r e c t p r o c e s s i n g leads to a r a t h e r c o n f u s i n g and troublesome s i t u a t i o n . Even f o r the s u p e r p o s i t i o n o p e r a t i o n , done by each i n s e r t c a l l , the i n t e r r e l a t i o n s h i p of p i c t u r e models i s r a t h e r ambiguous. Consider a p i c t u r e model: house :- door + window + roof The e q u i v a l e n t p r o c e s s i n g steps i n GKS i s the sequence of subr o u t i n e i n v o c a t i o n s as shown i n F i g u r e 14. CALL GEVTM(0.,0.,0.,0.,0., {evaluate t r a n s matrix} 1.,1.,0,tran1 ) CALL GCRSG(4) {create segment} CALL GINSG(1,tran1) { i n s e r t segment from WISS} CALL GINSG(2,tran1) CALL GINSG(3,tran1) CALL GCLSG {close segment} F i g u r e 14 - S u p e r p o s i t i o n Operation i n GKS where segments 1, 2, 3 and 4 represent the o b j e c t s door, window, roof and house. The parameter s e t t i n g s i n the GKS su b r o u t i n e s are not u n i q u e l y s p e c i f i e d . As a simple example, the range i n the c a l l of c e l l a r r a y appears as: CALL GCA(px,py,qx,qy,dx,dy,dimx,colla) Here, px, py and qx, qy correspond to the l o w e r - l e f t and upper-30 r i g h t hand cor n e r s of the c e l l a r r a y , which are arranged i n a vertex o r d e r . Yet the range i n the c a l l of n o r m a l i z a t i o n t r a n s f o r m a t i o n i s : CALL GSWN(tnr,xmin, xmax, ymin, ymax) in which the range of the window i s arranged i n an a x i s order of x and y i n s t e a d of a vertex o r d e r . The i r r e g u l a r i t y and incompleteness of the subroutine i n v o c a t i o n w i l l deter the e f f i c i e n c y and u t i l i z a t i o n of the system f u n c t i o n s . 3.2.3 Ambiguous A t t i b u t e S e t t i n g s By d e f i n i t i o n , besides p r o c e s s i n g f u n c t i o n s , the abundant a t t r i b u t e s e t t i n g s and i n q u i r y f a c i l i t i e s of GKS are a l s o bothersome f o r programmers. A t o p o l o g i c a l view of them i s given i n F i g u r e 15. ( A t t r i b u t e s ) ( Segment A t t r i b u t e s ) ^ P r i m i t i v e A t t r i b u t e s \ ( Polymarker ) ( Text (Something else) ( C e l l a r r a y ) i _ P _ o l y l i n e ^ ( F i l l a r e a j ( l i n e Type ( W i d t h S c a l e ) F i g u r e 15 - T o p o l o g i c a l View of GKS A t t r i b u t e s Each a t t r i b u t e i n i t s f a m i l y i s set by an i n t e g e r number 31 ra t h e r than an i n d i v i d u a l name. Consider the c o l o u r a t t r i b u t e , i t i s set i n GKS as i n F i g u r e 16. co l o u r GKS s e t t i n g blank 0 green 1 blue 2 orange 3 yellow 4 red 5 purple 6 white 7 F i g u r e 16 - The Colour A t t r i b u t e s of GKS The a t t r i b u t e of t e x t alignment i s set i n GKS as i n F i g u r e 17. te x t alignment GKS s e t t i n g ( h o r i z o n t a l ) normal 0 l e f t 1 cen t e r 2 r i g h t 3 ( v e r t i c a l ) normal ' 0 top 1 cap l i n e 2 h a l f 3 base l i n e 4 bottom 5 F i g u r e 17 - The Text Alignments of GKS B a s i c a l l y , numbers do not pro v i d e any c l u e f o r a programmer as to i t s meaning. The o v e r l a p p i n g of numeric val u e s f o r the s e t t i n g of p r i m i t i v e s , w o r k s t a t i o n s , segments and t r a n s f o r m a t i o n a t t r i b u t e s r e s u l t s i n a ra t h e r m i s l e a d i n g and c o n f u s i n g s i t u a t i o n . For example, the number 1 re p r e s e n t s green as a c o l o u r a t t r i b u t e , dot as a polymarker type a t t r i b u t e , segment 1 as a segment name a t t r i b u t e , e t c . The r e p e t i t i o n of numbers s t r o n g l y block programmers to choose the proper candidate d u r i n g 32 the assignment pr o c e s s . In a d d i t i o n , being b u i l t on a subroutine b a s i s , the GKS system c a r r i e s a l l the weaknesses and shortcomings of a subroutine package and presents i t s users the r e a l model of GKS s p e c i f i c a t i o n s r a t h e r than the v i r t u a l model at a higher l e v e l . From above a n a l y s i s , the h i g h - l e v e l GKS language (HL/GKS), designed on a l e v e l above the GKS system, i s s t u d i e d and implemented in t h i s t h e s i s . 33 IV. STUDIES ON THE HIGH-LEVEL GKS LANGUAGE (HL/GKS) 4.1 O b j e c t i v e s Being one important a p p l i c a t i o n area, g r a p h i c s languages should keep pace with the development of today's programming languages with regard to a b s t r a c t data s t r u c t u r e s and advanced programming f e a t u r e s . However, the development of h i g h - l e v e l g r a p h i c s languages i s s t i l l f a r from where i t c o u l d be. E i t h e r l o w e r - l e v e l drawing commands are performed or a set of subroutine p a t t e r n s i s i s s u e d . What s p e c i a l c h a r a c t e r i s t i c s of g r a p h i c s languages d i s t i n g u i s h e s today's programming languages? St i m u l a t e d by Wirth's d e f i n i t i o n on programming languages: "Programs = A l g o r i t h m s - + D a t a s t r u c t u r e s " , a s i m i l a r formula d e f i n i n g computer g r a p h i c s i s : "Computer Graphics D a t a s t r u c t u r e s + Computer Algorithms + Languages". A l l s t r u c t u r e s and advanced f e a t u r e s of programming languages are a l s o r e l e v a n t f o r the design of g r a p h i c s languages. From the software s u p p o r t i n g p o i n t of view, g r a p h i c s languages are c l a s s f i e d i n t o d i f f e r e n t l e v e l s as shown i n F i g u r e 18. Consider two c l a s s e s , subroutine packages and extended languages. Extended languages maintain more g r a p h i c a l s t r u c t u r e s and process f u n c t i o n s , which are very a p p e a l i n g f o r l e a r n i n g and u t i l i z i n g a language. GKS, b u i l t on a subroutine b a s i s , s u f f e r s from the shortage of h i g h - l e v e l programming f e a t u r e s and s t r u c t u r e s . As an i n t e r n a t i o n a l standard, GKS 34 L e v e l 0 no support L e v e l 1 subroutine or macro l i b r a r i e s a) low l e v e l b) high l e v e l L e v e l 2 language extension L e v e l 3 s p e c i a l purpose graphic languages a) g r a p h i c a l approaches b) command languages F i g u r e 18 - The L e v e l s of Software Support i n G r a p h i c a l Languages p r o v i d e s a l l the b a s i c g r a p h i c s f u n c t i o n s , t e r m i n a l f a c i l i t i e s and m u l t i p l e p r o c e s s i n g f o r general a p p l i c a t i o n s . On the other hand, being a subroutine o r i e n t e d system, GKS c a r r i e s i t s c o n t r o l s t a t e s , t r a n s f o r m a t i o n s , and f u n c t i o n i n v o c a t i o n s i n t o a poor background of frequent parameter assignments and subroutine c a l l s . I t i s the programmer's r e s p o n s i b i l i t y to maintain the proper s t a t e s , to set a t t r i b u t e s c o r r e c t l y and invoke a subroutine f o r each f u n c t i o n of GKS. As a simple example, a c r e a t e d segment can be d i s p l a y e d on an a c t i v e workstation from the open wor k s t a t i o n WISS (workstation independent segment s t o r a g e ) . T h e r e f o r e , to d i s p l a y a segment i n such way, a s e r i e s of a c t i o n s need to be performed, as presented i n F i g u r e 19. CALL GOPWK(1,8,100) {open WISS} CALL GOPWK(2,9,100000) {open a workstation} CALL GACWK(2) { a c t i v a t e the workstation} CALL GCSGWK(2,3) {copy segment 2} CALL GDAWK(2) {d e a c t i v a t e the workstation} CALL GCLWK(1) {close WISS} F i g u r e 19 - A Segment D i s p l a y i n GKS It i s p r e f e r a b l e to use a s i n g l e d i s p l a y statement i n a higher working environment, which r e p l a c e s a l l c o n t r o l d e t a i l s , e.g., d i s p l a y house on screen An abundant set of a t t r i b u t e s , which are grouped as to the 35 p r i m i t i v e they apply t o , pro v i d e v e r s a t i l e c h o i c e s f o r the d i s p l a y of p i c t u r e s . Consider the t e x t a t t r i b u t e , f o r which a t o p l o g i c view of i t s components i s given i n F i g u r e 20. T e x t A t t r i b u t e Path Colour. Spacing" Expansion ^ Fon t G P r e c i s i o r } Alignment 7 Upvector Height F i g u r e 20 - The T o p l o g i c View d l TexL A t t r i b u t e As p o i n t e d out be f o r e , the o v e r l a p of i n t e g e r v a l u e s r e p r e s e n t i n g the GKS a t t r i b u t e s can cause d i f f i c u l t i e s to a programmer when choosing the proper value of an a t t r i b u t e f o r assignment. Using a name r e f e r e n c e i n s t e a d of a number f o r the a t t r i b u t e assignment w i l l be more ac c e p t a b l e and reasonable, being more n a t u r a l and p r o v i d i n g c l a r i t y . A comparison of name and number assignments of the POLYLINE a t t r i b u t e i s shown i n Fi g u r e 21. Another major m o t i v a t i o n f o r the HL/GKS implementation i s to supplement g r a p h i c a l types, data s t r u c t u r e s , and programming 36 In HL/GKS: POLYLINE T(1:5) < TYPE: 'dash', COLOUR: 'yellow', WIDTH: 0.5 > In GKS: CALL GSLN(2) CALL GSPLCI(4) CALL GSLWSC(0.5) CALL GPL(5,tx,ty) { l i n e type assignment} {colour assignment} { l i n e width assignment} {POLYLINE output} F i g u r e 21 - Name and Number S e t t i n g of P o l y l i n e A t t r i b u t e s format i n terms of the g r a p h i c s syntax and semantics s p e c i f i e d i n the extended p o r t i o n of HL/GKS, e l e v a t i n g the poor background of the GKS system to a b e t t e r GKS programming s t y l e at a higher l e v e l . 4.2 G r a p h i c a l Types and S t r u c t u r e s D e r i v e d from GKS concepts, four g r a p h i c a l types are implemented i n the HL/GKS language: Each of them can be d e c l a r e d as a s i n g l e v a r i a b l e or as an a r r a y v a r i a b l e . S i n g l e v e c t o r s can r e p l a c e any c o o r d i n a t e p a i r i n GKS assignments or the output of p r i m i t i v e polymarker; an a r r a y v e c t o r then c o n s t r u c t s a s i n g l e output o b j e c t . Array segments supply the a l t e r n a t i v e s to some elements of a s t r u c t u r e d o b j e c t while a s i n g l e segment remains an i n d i v i d u a l e n t i t y . An a r r a y v e c t o r , segment, t r a n s , w o r k s t a t i o n . 37 t r a n s simulates the m u l t i p l e mapping of GKS c o o r d i n a t e space t r a n s f o r m a t i o n s . An ar r a y v a r i a b l e of type workstation produces m u l t i p l e output by the hardcopy t e r m i n a l . With the a r r a y type s u p p l i e d , g r a p h i c a l v a r i a b l e s of types v e c t o r , segment, t r a n s , and w o r k s t a t i o n can be e a s i l y processed together with the programming s t r u c t u r e s of the host language FORTRAN 77. The g r a p h i c a l d e c l a r a t i o n statements are kept c o n s i s t e n t with the other d e c l a r a t i o n statements of FORTRAN 77. Some i n s t a n c e s of g r a p h i c a l e x p r e s s i o n s of HL/GKS are pr o v i d e d i n F i g u r e 22. VECTOR v1(5), v 2 ( 5 ) , v3 SEGMENT window, house(3), door(3) TRANS n1(2) WORKSTATION p l o t t e r ( 3 ) , screen DO 10 i =1,3 house(i) = window + d o o r ( i ) 10 CONTINUE DO 20 i=1,5 IF s ( i ) > l 0 THEN v1 ( i ) = v 2 ( i ) - v3 20 ENDIF Fi g u r e 22 - Some G r a p h i c a l E x p r e s s i o n s of HL/GKS The type v e c t o r of HL/GKS i s expressed i n the form of (vx,vy) f o r the two-dimensional GKS s i t u a t i o n . O b v i o u s l y , i t i s e a s i l y extended to the thr e e - d i m e n s i o n a l space by the form of (vx,vy,vz). A v e c t o r v a r i a b l e can be assigned by a DATA statement of FORTRAN 77, a p a i r of r e a l numbers or r e a l e x p r e s s i o n s , or another v e c t o r v a r i a b l e " name. A vecto r i n i t i a l i z a t i o n i n a DATA statement can be f r e e l y i n t e r s p e r s e d with other types of FORTRAN 77. No c o n t i n u a t i o n c h a r a c t e r i s r e q u i r e d f o r the c r o s s - l i n e i n i t i a l i z a t i o n of a v e c t o r i n the DATA statement. The d i f f e r e n t forms of the v e c t o r assignment 38 are presented i n F i g u r e 23. VECTOR v l ( 2 ) , v s ( 6 ) , v2, v3(3) DATA vl/1.0,2.3; 3.8,4.5/, r1/2.0, 0.8/ DATA vs/0.0,0.0; 7.8,9.0; 5.4,2.8; 7.0,5.0; 8.4,9.0; 0.0,0.0/ v2 = (2.9, 1.8) v3(1) = v2 v3(2) = (r1 ,r2) v3(3) = ( 3 * s i n ( i ) + 5 . 2 , cos(i+2)/3.4) F i g u r e 23 - Vector Assignments of HL/GKS For convenience, the subelements of a vecto r can be s e l e c t e d with the post f i x .xcoord or .ycoord appended to the v e c t o r i d e n t i f i e r , e.g., v3(1) = (v2.xcoord+1.9, v2.ycoord) The v e c t o r operators a p p l i c a b l e to v e c t o r s are l i s t e d i n F i g u r e 24. + a d d i t i o n - s u b t r a c t i o n * s c a l a r product . dot product / s c a l a r d i v i s i o n F i g u r e 24 - The Vector Operators With the i n t r o d u c t i o n of the data type v e c t o r , g r a p h i c a l o b j e c t s are e a s i l y modelled and processed s i n c e they are based on v e r t i c e s , which form the necessary foundation for the a p p l i c a t i o n s of computational a l g o r i t h m s . Any c o o r d i n a t e p a i r can be assign e d by a v e c t o r name; p r i m i t i v e o b j e c t s are s p e c i f i e d by the i n d i c a t e d range of vecto r a r r a y s . F i g u r e 25 shows some common occurrences of the type v e c t o r i n HL/GKS. A l t e r n a t i v e l y , a subpart of a g r a p h i c a l o b j e c t can be s e l e c t e d by the r e l a t e d subrange of i t s v e c t o r such as: 39 VECTOR a t v , s c l v , t r e e ( 1 5 ) , t a b l e ( l O ) TEXT 'welcome to GKS' AT (1.5,0.8) TEXT ' t h i s i s a t e x t p r i m i t i v e ' AT atv s t a r < AT: (1.0,0.9), SCALE: (0.5,2.0) > s t a r < AT: atv, SCALE: s c l v > POLYLINE t r e e d : 1 5) FILLAREA table(1:10) F i g u r e 25 - Vector Placements i n HL/GKS POLYLINE tree(3:12) The type segment of HL/GKS d i r e c t l y r e f l e c t s segments of GKS. As from GKS, two working environments f o r segments are prov i d e d by the keywords OPEN and CLOSE. In the open environment, segment can be superimposed by p r e d e f i n e d p r i m i t i v e s and p r e v i o u s l y c r e a t e d segments w i t h i n i t s s p e c i f i e d c o o r d i n a t e space. In the c l o s e d environment, a segment can be modelled and processed by p r e v i o u s l y c r e a t e d segments through the s u p e r p o s i t i o n and d e l e t i o n f u n c t i o n s . A simple example of segment o p e r a t i o n s under both environments i s given i n F i g u r e 26. OPEN house house = POLYLINE square(1:5) + POLYMARKER handle + door + window(1) CLOSE f l a g = s t a r + s t a r s + frame house = house - window(l) + window(2) F i g u r e 26 - Segment Operations i n HL/GKS Environments The data type t r a n s of HL/GKS implements the 40 t r a n s f o r m a t i o n s of the GKS c o o r d i n a t e spaces. The mappings are s p e c i f i e d by r e c t a n g l e s . The r e c t a n g l e to be mapped from i s c a l l e d the window of a t r a n s f o r m a t i o n ; the r e c t a n g l e t o be mapped to i s c a l l e d the viewport of a t r a n s f o r m a t i o n . The keywords FROM and TO i n a t r a n s f o r m a t i o n p a t t e r n s i g n a l the window and viewport assignment of the t r a n s f o r m a t i o n , r e s p e c t i v e l y , such as: TRANS nt nt = < FROM: (3.8,2.9); (6.8,12.0) TO: (0.0,0.0); (0.5,1.0) > A window or viewport assignment which i s not s p e c i f i e d i n a tr a n s f o r m a t i o n p a t t e r n w i l l be set to the d e f a u l t assignment of GKS, v i z . (0.,0.) to (1.,1.), or the one assign e d p r e v i o u s l y . N o r m a l i z a t i o n t r a n s f o r m a t i o n s and work s t a t i o n t r a n s f o r m a t i o n s are d i s t i n g u i s h e d by the assignment c o n t e x t . A t r a n s f o r m a t i o n a s s i g n e d to an opened segment as the segment open a t t r i b u t e i s a n o r m a l i z a t i o n t r a n s f o r m a t i o n ; a t r a n s f o r m a t i o n assigned t o a viewing workstation as the wor k s t a t i o n viewing a t t r i b u t e i s a work s t a t i o n t r a n s f o r m a t i o n . A t r a n s f o r m a t i o n can be s p e c i f i e d e i t h e r by a t r a n s v a r i a b l e or by a t r a n s f o r m a t i o n p a t t e r n . Examples of t r a n s f o r m a t i o n assignments are presented i n F i g u r e 27. The input p r i o r i t y of n o r m a l i z a t i o n t r a n s f o r m a t i o n , to s e l e c t the t r a n s f o r m a t i o n order i n the normalized d e v i c e c o o r d i n a t e space, are i n d i c a t e d by the keywords of ABOVE and BELOW f o r each t r a n s f o r m a t i o n p a i r . OPEN house WITH n t ( l ) BELOW nt(2) 41 The data type w o r k s t a t i o n i s designed to minimize s t a t e TRANS nt(1) TRANS wt wt = n t d ) = OPEN house WITH nt(1) .DISPLAY house ON screen WITH wt 9 OPEN house WITH < FROM: (3.5,2.0); (4.8,7.0) > DISPLAY house ON p l o t t e r WITH < TO: (0.0,0.0);(3.6 , 5.8)> F i g u r e 27 - The A l t e r n a t e S e t t i n g s of Two Transformations assignments of workstations such as "workstation open", "workstation a c t i v e " , e t c . Workstations are opened when d e c l a r e d as a workstation type and a c t i v a t e d when r e f e r r e d to i n a d i s p l a y statement. Some long-term running w o r k s t a t i o n types are s y s t e m a t i c a l l y d e f i n e d i n the precompiler, which are e a s i l y changed f o r updating a c o n f i g u r a t i o n . The work s t a t i o n types used i n HL/GKS a r e : screen, p r i n t e r , p l o t t e r , . t4027, . t4025, . t4105, . t4112, . t4113, . t4115. The d i s p l a y f u n c t i o n s of GKS " a s s o c i a t e segment with w o r k s t a t i o n " and "copy segment to w o r k s t a t i o n " are expressed by the keywords SEND and DISPLAY i n a d i s p l a y statement of HL/GKS. 42 SEND house TO p l o t t e r DISPLAY house ON screen Using n a t u r a l names, workstations are much more d i s t i n c t l y c o n t r o l l e d and processed i n HL/GKS i n c o n t r a s t to the use of numeric r e f e r e n c e s of GKS. T h i s i s e s p e c i a l l y t r u e i n a m u l t i -workstation system. With the i n t r o d u c t i o n of g r a p h i c a l data types, more hi g h -l e v e l programming f e a t u r e s and freedom from s u p p l y i n g system f u n c t i o n d e t a i l s can be p r o v i d e d . Type d e c l a r a t i o n s , type checking, and type p a r s i n g of HL/GKS a i d i n d e t e c t i n g mismatched g r a p h i c a l types and a v o i d p a s s i n g i n c o r r e c t parameters to the GKS system. Using types, the f u n c t i o n s of the GKS system are simply performed as u n i t s by HL/GKS. D i s p l a y statements i n both GKS and HL/GKS are shown i n F i g u r e 28. CALL GOPWK(1,8,100) {open worksl} CALL GOPWK(2,9, 1 00000) {open works2.} CALL GACWK(2) { a c t i v a t e works2} CALL GSVP(1,0.,0.5,0.,1.0) {set viewportl} CALL GSELNT(1) { s e l e c t norm t r a n s l } CALL GCSGWK(2,3) {copy seg3 to works2} CALL GDAWK(2) {d e a c t i v a t e works2} CALL GCLWK(2) {close works2} CALL GCLWK(1) {close worksl} WORKSTATION p l o t t e r , screen TRANS n1,n2 n1 = DISPLAY house ON p l o t t e r WITH n1 Fi g u r e 28 - A D i s p l a y Fragment i n GKS and HL/GKS Language 43 4.3 HL/GKS Implementation HL/GKS i s implemented as a h i g h - l e v e l g r a p h i c s language on the b a s i s of the GKS system by a prec o m p i l e r . The precompiler i s s p e c i f i e d by two separate but i n t e r r e l a t e d f i l e s and generated with the Top-Down Compiler W r i t i n g System [Schr82]. The f i l e s of the precompiler a r e : i n t e g r a t e d BNF d e s c r i p t i o n f i l e , g l o b a l f i l e i n standard PASCAL. The source f i l e c o n t a i n s the syntax and semantics r u l e s of the language; the g l o b a l f i l e i s desi g n a t e d f o r a d d i t i o n a l semantics a c t i o n s . The i n t e r f a c e of the precompiler of HL/GKS to the CWS-TD system i s shown i n F i g u r e 29. CWS-TD System S o u r c e ^ G l o b a l > > P r e c o m p i l e r S e m a n t i ^ ( o p t i o n a l ' ) F i g u r e 29 - The I n t e r f a c e of the Precompiler of HL/GKS to the CWS-TD System The precompiler t r a n s l a t e s g r a p h i c a l statements of an HL/GKS program i n t o GKS s u b r o u t i n e s i n v o c a t i o n s which are then compiled by the FORTRAN 77 compiler and executed with the GKS runtime l i b r a r y . The sequence of t r a n s f o r m a t i o n steps of a HL/GKS program i s i l l u s t r a t e d i n F i g u r e 30. 44 5 cn o CL P r e c o m p i l a t i o n . _ > USER , OJ <" O ^ JO Jr o • e ro Ni cn CO o t_ CU C o m p i l a t i o n r - t-OJ -t •-< ( X C L »- e cr o o <-J OJ T j O O OJ JO o C o m p i l a t i o n •< ^ CO o. ; ? e CL o CJ IMPLEMENTATION F i g u r e 30 - The Transformation Steps of the HL/GKS Language To provide a b e t t e r working environment and on a higher l e v e l , most system c o n t r o l and s p e c i f i c a t i o n d e t a i l s of the GKS system are hidden or are t r a n s p a r e n t to the HL/GKS programmer. Thus, a HL/GKS programmer s p e c i f i e s the GKS f u n c t i o n s and f a c i l i t i e s i n h i s programs u n c o n s c i o u s l y and i m p l i c i t l y . Four system models are i n t e r n a l l y b u i l t up durin g the pre c o m p i l i n g phase by means of the g r a p h i c a l data types: v e c t o r model, segment model, t r a n s f o r m a t i o n model, work s t a t i o n model. The con c r e t e s t r u c t u r e of each of the models i s d e p i c t e d in F i g u r e 31 . „.,.'"" During p r e c o m p i l a t i o n , type checking, s t a t e changes, and f u n c t i o n mappings are c a r r i e d out based on the inf o r m a t i o n W o r k s t a t i o n Model 45 W-Index NAME INDEX p l o t t e r 1 o o o d o o T-Index T r a n s f o r m a t i o n Model NAME INDEX GIVEN • NT 1 No o o o o o o o o o V-Index V e c t o r Model NAME INDEX X Y SIGX SIGY GIVEN VI 0 0.6 0.2 T — yes o o o o o o o o o o o o o o o o o o o o o S-Index Segment Model NAME INDEX PRI SEG NEXT house 0 o p-Link o Link o Link o o o o o o o o 0 o o o o o o P-Link > NAME TYPES PRIMITIVE RECORD NEXT VS polyline o p - L i n k L i n k NAME INDEX IS-TRANS TRANS NEXT t r e e 2 yes tran8 j record o Link F i g u r e 31 - The S t r u c t u r e s of the Data Models 46 p r o v i d e d from above models. Consider the segment mode. Each e n t r y of the segment t a b l e c o n t a i n s three p o i n t e r s seg, p r i , and next. The p o i n t e r seg l i n k s a l l the present segment components of the entry segment which were c o n s t r u c t e d p r e v i o u s l y , the p o i n t e r p r i s t o r e s a l l the i n f o r m a t i o n of the output p r i m i t i v e s of the entry segment i n i t s opening s t a t e , and the p o i n t e r next c o l l e c t s a l l the superimposed segments which are r e f e r r e d to i n the present o p e r a t i o n . In a d d i t i o n , M-link i s a g l o b a l l y d e f i n e d p o i n t e r c h a i n which keeps a l l the segments which are to be d e l e t e d i n the present o p e r a t i o n . The tr a n s f o r m a t i o n s to be a s s o c i a t e d with each segment are a l s o recorded f o r each in s t a n c e of a model when needed. With models so c o n s t r u c t e d , the o p e r a t i o n s of s u p e r p o s i t i o n and d e l e t i o n of segments are executed based on the s t o r e d models; the system updates them both i n t e r n a l l y and e x t e r n a l l y . In HL/GKS, the two kinds of statements, namely host language and g r a p h i c s extension statements, can be i n t e r s p e r s e d f r e e l y i n a program. The g r a p h i c a l statements of HL/GKS are i d e n t i f i e d and t r a n s l a t e d by the f o l l o w i n g s t e p s : l e x i c a l scan, s y n t a c t i c p a r s i n g , semantic a n a l y s i s , and GKS code g e n e r a t i o n . A language L(G), produced by a grammar G, i s formulated as: L(G) = { SeT* | S ==> s } Here, T a f i n i t e set of t e r m i n a l symbols, S non-terminal s t a r t symbol, s l e g a l sentence i n language. A c c o r d i n g l y , the g r a p h i c a l extension of a language must f o l l o w the same d e f i n i t i o n . What syntax and semantics r u l e s need to be 47 s u p p l i e d f o r the HL/GKS language? What l e x i c a l l ayout i s adopted f o r the g r a p h i c a l p a r t of HL/GKS? To answer these q u e s t i o n s , the implementation of HL/GKS i s e x p l o r e d from the f o l l o w i n g a s p e c t s : l e x i c a l usage, syntax r u l e s , semantics r u l e s . 4.3.1 L e x i c a l Usage In HL/GKS, a l l i d e n t i f i e r s and keywords can be entered using e i t h e r lower case or upper case c h a r a c t e r s . I n t e r m i x i n g of c h a r a c t e r s i s a c c e p t a b l e and not d i s t i n g u i s h e d . For in s t a n c e , the keywords VECTOR, v e c t o r or VecTor are e q u i v a l e n t . No c o n t i n u a t i o n mark i n column 6 i s r e q u i r e d to f l a g the c o n t i n u a t i o n of a l i n e of a g r a p h i c a l statement as long as the proper syntax r u l e s f o r the statement are f o l l o w e d . An example of a g r a p h i c a l layout of HL/GKS i s presented i n F i g u r e 32. curve = POLYLINE x s i n ( l : 5 l ) + TEXT 'sine curves' AT (0.05,0.1) F i g u r e 32 - The G r a p h i c a l Layout of HL/GKS Other c a r d r e s t r i c t i o n s of FORTRAN 77, such as c h a r a c t e r s "C" or "*" i n column 1 f o r a comment l i n e , columns 2 to 5 f o r statement l a b e l s , and columns 7 t o 72 f o r language statements are not e f f e c t i v e f o r the layout of g r a p h i c a l statements of HL/GKS. Labels can be set i n columns 7 t o 72, some programming p o r t i o n can be expressed i n columns 2 t o 5. Blank l i n e s may be used i n HL/GKS programs f o r improved r e a d a b i l i t y . Comments i n c l u d e d 48 between the d e l i m i t e r s "{" and "}" can be f r e e l y p l a c e d i n HL/GKS, and w i l l be ignored d u r i n g the pr e c o m p i l i n g p r o c e s s . Two loop s t r u c t u r e s are s u p p l i e d by HL/GKS to have more c o n t r o l on the language flow. F i g u r e 33 shows the s y n t a c t i c a l e x p r e s s i o n of the s t r u c t u r e s . WHILE DO ENDWHILE REPEAT UNTIL F i g u r e 33 - S y n t a c t i c a l E x p r e s s i o n of New S t r u c t u r e s Block compiling i s p o s s i b l e i n the pr e c o m p i l i n g phase of HL/GKS to g i v e freedom of model programming and l o c a l debugging. The main block and subroutine b l o c k s of a program may be compiled s e p a r a t e l y or i n an a r b i t a r y sequence, which i s represented i n the syntax r u l e o f : ::= {
| }, A l l g r a p h i c a l data types can be passed to a subroutine when d e c l a r e d i n i t s parameter l i s t . The d e c l a r a t i o n of the g r a p h i c a l types i n subroutine blocks f o l l o w s the same d e c l a r a t i o n r u l e as f o r the main b l o c k . I d e n t i f i e r s f o r a l l g r a p h i c a l data types except v e c t o r can be up to 15 c h a r a c t e r s long, p r o v i d i n g a more reasonable r e f e r e n c e of a f u l l name. Vector i d e n t i f i e r s are p r e s e n t l y r e s t r i c t e d t o 5 c h a r a c t e r s as each v e c t o r v a r i a b l e w i l l be t r a n s l a t e d i n t o a p a i r of r e a l v a r i a b l e s i n the compiled output. 49 If the programmer r e f r a i n s from i n t r o d u c i n g i d e n t i f i e r s b eginning with the c h a r a c t e r s G or g, no c o n f l i c t s w i l l a r i s e with the i d e n t i f i e r s of the GKS system. 4.3.2 Syntax Rules As p o i n t e d out e a r l i e r , the syntax of the GKS system i s mainly represented by the f o l l o w i n g a s p e c t s : s t a t e flows, subroutine p r o t o c o l s . GKS should always be i n one of the f o l l o w i n g s t a t e s : GKS c l o s e d ( a ) , GKS open (b), at l e a s t one work s t a t i o n open ( c ) , at l e a s t one wo r k s t a t i o n a c t i v e ( d), at most one segment open ( e ) . State changes are r e s t r i c t e d to a s e q u e n t i a l order of flow i n both d i r e c t i o n s . Within each f l a g g e d s t a t e , only some subr o u t i n e s can be l e g a l l y invoked. As a r e s u l t , i n GKS i t i s the programmer's r e s p o n s i b i l i t y to be i n the proper s t a t e f o r l e g a l s ubroutine i n v o c a t i o n s . In HL/GKS, only one s t a t e r e s t r i c t i o n i s imposed on the programmer: at most one segment open O u t l i n e s of the s t a t e s i n both languages are presented i n Fig u r e 34. The other s t a t e s are i n t e r n a l l y c o n t r o l l e d by the precompiler a c c o r d i n g the syntax and semantics d e f i n i t i o n of HL/GKS. The BEGIN statement i n the main block s e t s the s t a t e of "at l e a s t one w o r k s t a t i o n a c t i v e " through the s t a t e s of "GKS open" and "at In GKS In HL/GKS F i g u r e 34 - The O u t l i n e s of the St a t e s i n Both Languages l e a s t one work s t a t i o n open"; the END statement i n the main block r e t u r n s the system to the s t a t e of "GKS c l o s e d " . The s t a t e of "at most one segment open" i s o p t i o n a l l y switched on or o f f by the a p p r o p r i a t e statements of HL/GKS. The segment open statement s e t s the s t a t e o f "at most one segment open" on; the segment c l o s e statement turns i t o f f . With only one s t a t e o u t l i n e d , the g r a p h i c a l statements of HL/GKS are simply p a r t i t i o n e d i n t o two groups, "segment open" and "segment not open". A d i s p l a y statement (to copy segments to the s p e c i f i e d w orkstations) may not be i s s u e d i n the s t a t e "segment open", the c l e a r statement (to c l e a r a l l segments from the s p e c i f i e d w o r k stations) i s a l s o not accepted when a segment i s open. The "segment c l o s e d " environment i s assumed to be the s t a t e i n each subroutine b l o c k , unless i t has been changed with the keyword OPEN appended t o a segment parameter. SUBROUTINE f i n d ( ts:OPEN, r) SEGMENT t s Few r e s t r i c t i o n s on s t a t e changes f o r proper f u n c t i o n execution are l e v i e d on a HL/GKS programmer. Using the language e x t e n s i o n approach, HL/GKS removes the 51 r e s t r i c t i o n s of the sub r o u t i n e s p r o t o c o l of GKS. The GKS c o n t r o l and system s p e c i f i c a t i o n s are a b s t r a c t e d and i n c o r p o r a t e d i n t o the HL/GKS d e f i n i t i o n . The major components of the GKS system are presented i n F i g u r e 35. ( S e g m e n t ) (WoDcstatlorT) (rransforMtlons) f Works Trans) F i g u r e 35 - The Major Components of the GKS System F i v e standard output p r i m i t i v e s are d e f i n e d i n the GKS document: p o l y l i n e , polymarker, f i l l a r e a , c e l l a r r a y , t e x t . Instead of in v o k i n g a subroutine f o r each p r i m i t i v e , keywords are combined with v e c t o r s to represent p r i m i t i v e s . The keywords v i a the p r i m i t i v e names i n d i c a t e the output types; a modelled v e c t o r a r r a y resembles the s t r u c t u r e d o b j e c t through the f e a t u r e p o i n t s i n the v e c t o r . Some examples of p r i m i t i v e g e n e r a t i o n i n HL/GKS are presented in F i g u r e 36. For convenience, the p r i m i t i v e c e l l a r r a y i s s p e c i f i e d based on a 52 POLYLINE pg(1:10) POLYMARKER mg(1:10) FILLAREA fg(3:1u) CELLARRAY c o l i a ( d x , d y ) TEXT 'GOODBYE' AT (ax,ay) F i g u r e 36 - Output Examples of HL/GKS two-dimensional r e a l a r r a y . A p p r o p r i a t e a t t r i b u t e s may be a p p l i e d to an output p r i m i t i v e which are subsequently a s s i g n e d to each p r i m i t i v e keyword to form a whole p r i m i t i v e concept. Two assignment approaches of bundled and i n d i v i d u a l a t t r i b u t e s of GKS are implemented i n HL/GKS. The keyword TABLE set i n the a t t r i b u t e p a t t e r n f l a g s the bundled f u n c t i o n of GKS; the assignment of an a t t r i b u t e p l a c e s each a t t r i b u t e to i n d i v i d u a l one at a time. An assignment of type i n d i v i d u a l i s s p e c i f i e d by a r e l a t e d keyword, d i r e c t l y i n f e r r e d from the GKS document, such as TYPE, COLOUR, and FONT. Common a t t r i b u t e s of p r i m i t i v e s are d i s t i n g u i s h e d by the assignment c o n t e x t . For example, the keyword TYPE r e f e r s to e i t h e r a type of p o l y l i n e or a type of polymarker. Parameters of two data types, CHARACTER and REAL, are used i n a t t r i b u t e assignments and the examples are the a t t r i b u t e COLOUR, set by the name of the c o l o u r , and the a t t r i b u t e SPACE, set by a number of type r e a l . Constants, v a r i a b l e s , as w e l l as e x p r e s s i o n s are a c c e p t a b l e i n assignment statements. S e v e r a l a l t e r n a t i v e a t t r i b u t e s assignments are shown in F i g u r e 37. M u l t i p l e p r i m i t i v e s p e c i f i c a t i o n of the same p r i m i t i v e type i s supported i n HL/GKS, but s t i l l a l l o w i n g i n d i v i d u a l a t t r i b u t e assignment f o r each p r i m i t i v e . An i n s t a n c e of a m u l t i p l e 53 POLYLINE POLYLINE POLYLINE CHARACTER*5 ptype ptype = 'dash' r1 = 0.6 -POLYLINE F i g u r e 37 - A l t e r n a t i v e S e t t i n g s of A t t r i b u t e s assignment of the p r i m i t i v e p o l y l i n e i s given i n F i g u r e 38. house = POLYLINE round(1:16); block(2:20); side(1:5) F i g u r e 38 - M u l t i p l e Output of the P r i m i t i v e P o l y l i n e The w o r k s t a t i o n independent segment storage (WISS) i s opened and a c t i v a t e d at the time of system opening to provide a g l o b a l p r o c e s s i n g environment f o r segments. Other workstations are opened when d e c l a r e d i n the d e c l a r a t i o n statement and a c t i v a t e d when r e f e r r e d i n the d i s p l a y statement. T h i s use of workstations combined with the g l o b a l m o d e l l i n g of segments s i m p l i f i e d most system r e s t r i c t i o n s . The u t i l i z a t i o n of input f u n c t i o n s a l l o w s an i n t e r a c t i v e approach to p i c t u r e m o d e l l i n g . P i c t u r e s can be d e f i n e d by t h e i r v e r t i c e s read o n - l i n e , a v o i d i n g input by meaningless data p a t t e r n s . The g r a p h i c a l input statements of HL/GKS are implemented i n a form c o n s i s t e n t with the input statements of FORTRAN 77. They a r e : READ (wkid, d e v i c e t y p e ) g r a p h i c a l v a r i a b l e 54 { , g r a p h i c a l v a r i a b l e } In comparison to FORTRAN 77, wkid resembles the l o g i c u n i t name from which data i s to be read while d e v i c e t y p e i m i t a t e s the read format s p e c i f i c a t i o n to be a p p l i e d . F i v e l o g i c input d e v i c e s of GKS are implemented i n the HL/GKS language as: l o c a t o r , s t r i n g , s t r o k e , v a l u a t o r , c h o i c e . Each l o g i c d e v i c e i s d i s t i n g u i s h e d by the type of g r a p h i c a l v a r i a b l e s which i s s p e c i f i e d i n the input statement. The corresponding data types f o r the l o g i c d e v i c e s are l i s t e d i n F i g u r e 39. F i g u r e 39 - The Data Types f o r the Lo g i c Devices Two t r a n s f o r m a t i o n s , n o r m a l i z a t i o n t r a n s f o r m a t i o n and works t a t i o n t r a n s f o r m a t i o n , d e f i n e d i n the GKS document to a i d i n device independence, are combined i n one t r a n s f o r m a t i o n type (type t r a n s ) and are d i s t i n g u i s h e d by d i f f e r e n t s y n t a c t i c a l assignment r u l e s . When a t r a n s v a r i a b l e i s as s i g n e d to an open segment statement, i t r e f e r s to a n o r m a l i z a t i o n t r a n s f o r m a t i o n , otherwise to a wor k s t a t i o n t r a n s f o r m a t i o n a s s i g n e d to a viewing w o r k s t a t i o n . L o g i c Device Data Type l o c a t o r s t r i n g s t r o k e v e c t o r c h a r a c t e r a r r a y v e c t o r r e a l i n t e g e r v a l u a t o r c h o i c e 55 The c l i p p i n g f u n c t i o n of the GKS t r a n s f o r m a t i o n , to remove the o v e r l a p p i n g part of the c l i p p i n g r e c t a n g l e ( n o r m a l i z a t i o n t r a n s f o r m a t i o n viewport) with a work s t a t i o n window on NDC space, i s f l a g g e d on or o f f by the statements CLIPPING ON or CLIPPING OFF, r e s p e c t i v e l y . In GKS, one or s e v e r a l segments can be d i s p l a y e d on one or s e v e r a l w o r k s t a t i o n s by means of the d i s p l a y statement. The symbols of "+" and "," serve as sep a r a t o r s on the m u l t i p l e assignment of segments and wo r k s t a t i o n s in an output statement. As f o r GKS, output p r i m i t i v e s i s s u e d d u r i n g s t a t e are "segment c l o s e d " i n c l u d e d i n the d i s p l a y streams of HL/GKS. The two segment viewing a t t r i b u t e s v i s i b i l i t y and h i g h l i g h t i n g can be assi g n e d to a segment name i n the d i s p l a y statement. F i g u r e 40 shows s e v e r a l statements i n HL/GKS which cause m u l t i p l e output. VECTOR v s t a r • • • DISPLAY t r e e + house ON screen DISPLAY f l a g , polymarker v s t a r ON screen, p l o t t e r REDRAW 4027, 4014 SEND curve, t i t l e + a x i s TO p l o t t e r F i g u r e 40 - M u l t i p l e Output D i s p l a y Statements of HL/GKS A comparison of m u l t i p l e output i n HL/GKS and GKS i s given i n F i g u r e 41. The d e t a i l e d syntax r u l e s of the HL/GKS exte n s i o n are presented i n BNF form i n Appendix A. 56 4.3.3 Semantics Rules In HL/GKS: DISPLAY f l a g , f l a g s ON screen, p l o t t e r , p r i n t e r In GKS: CALL GOPWK(2,9,100000) CALL GOPWK(3,10,100000) CALL GOPWK(4,11,100000) CALL GACWK(2) CALL GACWK(3) CALL GACWK(4) CALL GCSGWK(2,1) CALL GCSGWK(2,2) CALL GCSGWK(3,1) CALL GCSGWK(3,2) CALL GCSGWK(4,1) CALL GCSGWK(4,2) CALL GDAWK(4) CALL GDAWK(3) CALL GDAWK(2) CALL GCLWK(2) CALL GCLWK(3) CALL GCLWK(4) F i g u r e 41 - M u l t i p l e Output i n HL/GKS and GKS Implemented on the b a s i s of GKS, the semantical d e f i n i t i o n s of HL/GKS have been kept as c l o s e as p o s s i b l e to the GKS concepts. The keyword BEGIN i n a main block opens the GKS system and the d e c l a r e d w o r k s t a t i o n s ; the keyword END i n the main block c l o s e s the system and a l l w o r k s t a t i o n s . The assignment r u l e s of GKS are a p p l i e d i n HL/GKS. A t t r i b u t e s and t r a n s f o r m a t i o n s which are not as s i g n e d a s p e c i f i c value are assigne d d e f a u l t v a l u e s . As examples, the d e f a u l t value f o r the a t t r i b u t e p o l y l i n e type i s s o l i d ; the d e f a u l t viewport of a n o r m a l i z a t i o n t r a n s f o r m a t i o n i s the e n t i r e NDC space. A value once a s s i g n e d w i l l be e f f e c t i v e u n t i l a new value i s a s s i g n e d . Some i n s t a n c e s of assignments are given i n F i g u r e 42. 57 OPEN t r e e s WITH nt CLOSE OPEN house house:- POLYLINE ou t s ( 1 : 5 ) ; l e f t ( 1 : 5 ) ; r i g h t ( l : 5 ) CLOSE F i g u r e 42 - Some Assignment Instances of HL/GKS In F i g u r e 42, the n o r m a l i z a t i o n t r a n s f o r m a t i o n nt i s assigned to the segments t r e e s and house; the a t t r i b u t e p o l y l i n e type dash i s a s s i g n e d to the p o l y l i n e s l e f t and r i g h t while the d e f a u l t value s o l i d i s used f o r the a t t r i b u t e of p o l y l i n e outs. A grammar f o r a language to be parsed by the Compiler W r i t i n g System i s r e q u i r e d to be of type L L ( 1 ) ; i t determines the language p a r t s by only one c h a r a c t e r look ahead from i t s l e f t - m o s t d e r i v a t i o n , and i n the order of l e f t to r i g h t . T h e r e f o r e , c e r t a i n g r a p h i c a l symbols and o p e r a t o r s are s p e c i f i e d i n the extended p o r t i o n of HL/GKS to allow proper language p a r s i n g . The symbols "<" and ">" act as d e l i m i t e r s of a t t r i b u t e assignments; the symbol ":" precedes each parameter i n an i n d i v i d u a l assignment. The o p e r a t o r s "+" and "-" are overloaded and have d i f f e r e n t meanings f o r each process type. They are r e f e r r e d to as v e c t o r a d d i t i o n and s u b t r a c t i o n f o r the v e c t o r operands or as segment s u p e r p o s i t i o n and d e l e t i o n f o r the segment operands. The semantics of the g r a p h i c a l symbols and op e r a t o r s i n the HL/GKS d e f i n i t i o n i s presented i n F i g u r e 43. No s p e c i a l symbol i s a p p l i e d f o r the g r a p h i c a l assignment of HL/GKS, i t i s parsed by means of the system semantics checking on each g r a p h i c a l type, thus u n i f y i n g the concept of 58 < l e f t d e l i m i t e r of a t t r i b u t e assignment > r i g h t d e l i m i t e r of a t t r i b u t e assignment : i n d i v i d u a l a t t r i b u t e assignment ; d e l i m i t e r of v e c t o r s , d e l i m i t e r of m u l t i p l e a t t r i b u t e s , segments and workstations + v e c t o r a d d i t i o n or segment s u p e r p o s i t i o n v e c t o r s u b t r a c t i o n or segment d e l e t i o n * v e c t o r product with a s c a l a r / v e c t o r d i v i s i o n by a s c a l a r v e c t o r dot product F i g u r e 43 - The Semantics of Symbols and Operators of HL/GKS g r a p h i c a l and nongraphical assignment. For segment m o d e l l i n g , a segment o b j e c t may be modelled l e v e l up with r e f e r e n c e to i t s e l f or r e d e f i n e d d i r e c t l y by other segment components. house = house + t r e e house = t r e e Each d e c l a r e d workstation i s matched with the standard workstation types of HL/GKS to check any misuse of work s t a t i o n types. The g r a p h i c a l input statements of HL/GKS are d i s t i n g u i s h e d from the read statements of FORTRAN 77 by the i d e n t i f i e r s wkid and d e v i c e t y p e . The f i v e l o g i c d e v i c e s of GKS are parsed by the type of the g r a p h i c a l v a r i a b l e i n the read statement. For example, the data read from the de v i c e l o c a t o r should be a p a i r of r e a l numbers, which are represented by the type v e c t o r i n HL/GKS. No d i s t i n c t i o n i s made between the format of g r a p h i c a l input statements, FORTRAN input statements, or l o g i c d e v i c e input statements. Two kinds of de v i c e types of GKS (keyboard and g r a p h i c a l t a b l e t ) are r e f e r r e d to by l i t e r a l s i n the read 59 statement of HL/GKS. F i g u r e 44 demonstrates read statements of HL/GKS of each l o g i c d e v i c e . CHARACTER*10 t i t l e , a x i s VECTOR vp1,vp2,vps(10) REAL rs1,rs2 INTEGER c i 1 ,ci2 READ (4027, keyboard)vp1 {locator} READ (screen,keyboard) t i t l e {string} READ (4027, t a b l e t ) vps(1:10) {stroke} READ (4012, keyboard) rs1 {valuator} READ (screen,keyboard)ci1 {choice} F i g u r e 44 - Read Statements of HL/GKS More than one v a r i a b l e (but of same type) may appear i n the l i s t of an input statement. A subrange can be s p e c i f i e d by an upper and lower bound of v e c t o r a r r a y f o r input of the str o k e d e v i c e . READ (4027, keyboad) v p l , vp2 READ (4027, t a b l e t ) vps(2:8) 60 V. EXAMPLES OF GKS AND HL/GKS LANGUAGE PROGRAMS There are four examples presented i n the f o l l o w i n g s e c t i o n . Example 1 and Example 2 are given both i n HL/GKS and GKS, the programs produce the i d e n t i c a l p i c t u r e output, and provide a d i r e c t comparison f o r an e v a l u a t i o n of the HL/GKS implementation. Example 3 and Example 4 i n HL/GKS show f u r t h e r c h a r a c t e r i s t i c s and a p p l i c a t i o n examples of the HL/GKS language. Each output produced f o l l o w s the program l i s t i n g to present the v i s u a l e f f e c t s . Among the examples, Example 1 i s taken from the o r i g i n a l demonstration example of the GKS document. 61 { } { EXAMPLE 1 IN HL/GKS } SEGMENT CURVE CHARACTER*9 SETS VECTOR XSIN(51) WORKSTATION PLOTTER, SCREEN BEGIN {GKS} OPEN CURVE WITH MESSAGE 'GKS CAN GENERATE TEXT' ON SCREEN CURVE= TEXT 'SINE CURVES' AT (0.05,0.0) MESSAGE 'GKS CAN GENERATE POLYLINES' ON SCREEN DO 10 K=1,51 R1 = FLOAT(K-1)*0.02 XSIN(K)= (R1, SIN(R1*6.283)) 10 CONTINUE CURVE= CURVE + POLYLINE XSIN(1:51) DO 30 K=1,3 DO 20 KK=1,51 20 XSIN.YCOORD(KK)=XSIN.YCOORD(KK)*0.667 GO TO (1,2,3),K 1 SETS= 'DASH' GO TO 35 2 SETS= 'DOT' GO TO 35 3 SETS= 'DASHDOT' 35 CURVE= CURVE + POLYLINE XSIN(1:51) 30 CONTINUE MESSAGE 'GKS CAN GENERATE POLYMARKERS' ON SCREEN DO 40 K=1,21 R1 = FLOAT(K-1)*0.05 XSIN(K)= (R1, -SIN(R1*6.283)) 40 CONTINUE CURVE= CURVE + POLYMARKER XSIN(1:21) DO 60 K=1,5 DO 50 KK=1,21 50 XSIN.YCOORD(KK)=XSIN.YCOORD(KK)*0.75 GO TO (5,6,7,8,9),K 5 SETS= 'DOT' GO TO 65 6 SETS= 'PLUS' GO TO 65 7 SETS= 'CIRCLE' 62 GO TO 65 8 SETS= 'CROSS' GO TO 65 9 SETS= 'SQUARE' 65 CURVE= CURVE + POLYMARKER XSIN(1:21) 60 CONTINUE CLOSE DISPLAY CURVE ON PLOTTER STOP END PROGRAM DEM01 T h i s program demonstrates how GKS may be used The f o l l o w i n g p r i m i t i v e s w i l l be used: - POLYLINE - POLYMARKER - TEXT INTEGER K,L,M REAL SINX(51),SINY(51),TWOPI/6.28318/ CHARACTER *7 FNAME, CFNAME Open u n i t 21, the e r r o r message f i l e . The open statement a t t a c h e s the u n i t to the temporary f i l e "-GKSERR". FNAME = '-GKSERR' OPEN (UNIT=21,FILE=FNAME,STATUS='UNKNOWN') S p e c i f y the output m e t a f i l e . I t i s assig n e d to u n i t 20. CFNAME = '-METAFL' OPEN (UNIT=20,FILE=CFNAME,IOSTAT=IOS,STATUS='UNKNOWN') IF (IOS.NE.0) THEN WRITE(6,*) 'Cannot open output m e t a f i l e ' STOP END IF Open the G r a p h i c a l K e r n e l System CALL GOPKS(21) Open and a c t i v a t e a w o r k s t a t i o n . The w o r k s t a t i o n s e l e c t e d i s " m e t a f i l e out" d e f i n e d by the systems constant '100000'. CALL GOPWK(1,20,100000) CALL GACWK(1) Define and s e l e c t a t r a n s f o r m a t i o n that d i r e c t s output to a window of (0.0,1.0) x (-1.0,1.0) CALL GSWN(1,0.0,1.0,-1.0,1.0) CALL GSELNT(1) Begin output: S t a r t with a set of p o l y l i n e s , to be output with four d i f f e r e n t l i n e t y p e s s t a r t i n g with the d e f a u l t (1 = s o l i d ) CALL GMSG(1,'GKS can generate p o l y l i n e s ' ) DO 10 K=1,51 SINX(K) = FLOAT(K-1)*0.02 SINY(K) = SIN(SINX(K)*TWOPI) 10 CONTINUE CALL GPL(51,SINX,SINY) DO 30 K=2,4 L = K CALL GSLN(L) DO 20 M=1,51 SINY(M) = SINY(M)*0.667 20 CONTINUE CALL GPL(51,SINX,SINY) 30 CONTINUE Next output a set of polymarkers s t a r t i n g with the d e f a u l t marker (3 = a s t e r i s k ) CALL GMSG(1,'GKS can generate polymarkers') DO 40 K=1,21 SINX(K) = FLOAT(K-1)* 0.0 5 SINY(K) = -SIN(SINX(K)*TWOPI) 40 CONTINUE CALL GPM(21,SINX,SINY) DO 60 K=1 , 5 M = K CALL GSMK(M) DO 50 M=1,21 SINY(M) = SINY(M)*0.75 50 CONTINUE CALL GPM(21,SINX,SINY) 60 CONTINUE F i n a l l y , output a t e x t s t r i n g - d e f a u l t i s font 1, s e l e c t a reasonable c h a r a c t e r height and spacing CALL GMSG(1,'GKS can generate t e x t ' ) CALL GSCHH(0.03) CALL GSCHSP(0.80) CALL GTX(0.05,0.00,'sine curves') D e a c t i v a t e and c l o s e the w o r k s t a t i o n and GKS CALL GDAWK(1) CALL GCLWK(1) CALL GCLKS STOP END 65 66 { } { EXAMPLE 2 IN HL/GKS } subroutine maker( r a d i u s , v) { generate up the v e c t o r s of a c i r c l e } r e a l r a d i u s v e c t o r v(37) begin angle= 0.0 do 10 i=1,37 r= angle* 3.14159/180. v ( i ) = ( r a d i u s * c o s ( r ) + 1 . 5 , r a d i u s * s i n ( r ) + 1 . 5 ) angle= angle+10 10 continue r e t u r n end SEGMENT CIRCLES, SUBCIR, TITLE(2), CURVE(2), XAXIS, YAXIS, FRAME, PICTURE(2) VECTOR CUR(38), ROUND(37), POINT(2), CUR1O00), CUR2O00), SIDE(5) TRANS NT(2) WORKSTATION PLOTTER, T4014 DATA SIDE/0.0,0.0; 3.0,0.0; 3.0,2.0; 0.0,2.0; 0.0,0.0/ BEGIN {GKS open} { set two t r a n s f o r m a t i o n s } NT(1)= NT(2)= ANGLE= 0.0 DO 10 1=1, 38 R=ANGLE* 3.14159/180. CUR(I)=( 0.2*(COS(R)+R*SIN(R))+1.3, 0.2*(SIN(R)-R*COS(R))+1.5) ANGLE= ANGLE+10. 10 CONTINUE { c r e a t e the images on the upper-half plane of output } OPEN CIRCLES WITH NT(1) R=0.2 CALL MAKER(R,ROUND) CIRCLES= POLYLINE R0UND(1:37) 67 DO 20 1=1,6 R=R+0.1 CALL MAKER(R,ROUND) CIRCLES= CIRCLES+POLYLINE R0UND(1:37) 20 CONTINUE CLOSE OPEN SUBCIR CALL NUMBER(0.0,0.3,30.0,SUBCIR) CALL NUMBER(0.3,0.6,15.0,SUBCIR) CALL NUMBER(0.6,0.8,4.0,SUBCIR) CLOSE OPEN CURVE(1) CURVE(1)= POLYLINE CUR(1:38) DO 30 1=1,19 CUR(I)=(CUR.XCOORD(2*I), CUR.YCOORD(2*1)) 30 CONTINUE CURVE(1)= CURVE(1)+POLYMARKER CUR(1:19) CLOSE OPEN TITLE(1) TITLE(1)= TEXT 'A POLAR PLOT WITH GRID' AT (0.6,2.6) CLOSE PICTURE(1)= TITLE(1)+ CURVE(1) < SCALE: (0.5,0.7) AT: (1.5,1.5) > + CIRCLES { c r e a t e the images on the lower-half plane of output } OPEN TITLE(2) WITH NT(2) TITLE(2)= TEXT 'XGRAF WITH A GRID' AT (0.5,2.5) CLOSE OPEN FRAME FRAME= POLYLINE SIDB(1:5) P0INT(1)= (0.0,0.0) POINT(2)= (0.0,2.0) DO 50 1=1,10 DO 60 J=1,2 60 POINT.XCOORD(J)=POINT.XCOORD(J)+0.3 FRAME= FRAME+POLYLINE P0INT(1:2) 50 CONTINUE 68 P0INT(1)= (0.0,0.0) POINT(2)= (3.0,0.0) DO 7 0 1=1,10 DO 80 J=1 ,2 80 POINT.YCOORD(J)=POINT.YCOORD(J)+0.2 FRAME= FRAME+ POLYLINE P0INT(1:2) 70 CONTINUE CLOSE DO 90 1=1,100 X= FLOAT(I)/ 100. CUR1 (I ) = (X*3.0,EXP(-3.*X)*SIN(X*8.*3.14159) + ! .0) CUR2(I)=(X*3.0,EXP(-3.*X)*COS(X*8.*3.14159)+1.0) 90 CONTINUE OPEN CURVE(2) CURVE(2)=POLYLINE CUR1(1:100); CUR2(1:100) CLOSE OPEN XAXIS XAXIS= TEXT '0.0 0.1 0.2 0.3 0.4 0.5 0.6' AT ( _0.1 -0.2)* '0.7 0.8 6.9*1.6' AT (1.96, -0.2); < HEIGHT: 0.08, SPACE: 0. 1 5> 'X AXIS WITH GRAF TYPE' AT (0.5,-0.5) CLOSE OPEN YAXIS YAXIS= TEXT '-1.0 -0.6 -0.2 +0.2 +0.6 +1.0' AT (-0.1,-0.1); 'Y AXIS WITH GRAF TYPE' AT (-0.32,0.2) CLOSE PICTURE(2)= FRAME+ CURVE(2)+ TITLE(2)+ XAXIS+ YAXIS DISPLAY PICTURE(2) ON PLOTTER DISPLAY PICTUREO), SUBCIR ON PLOTTER STOP END {GKS C l o s e } { number the r a d i u s l i n e s between two c i r c l e s } SUBROUTINE NUMBER(r1,r2,degree,sub:OPEN) VECTOR p(2) SEGMENT sub REAL degree BEGIN 69 angle= 0.0 j=360./degree DO 10 I=1,j p(1)= (r1*COS(angle)+1.5, r1*SIN(angle)+1.5) p(2)= (r2*COS(angle)+1.5, r2*SIN(angle)+1.5) sub= sub+ POLYLINE p ( l : 2 ) angle=angle+degree*3.14159/180. 10 CONTINUE RETURN END EXAMPLE 2 IN GKS generate two c i r c l e a r r a y s SUBROUTINE MAKER(RIDUS,VX,VY) REAL VX(37),VY(37) REAL RIDUS ANGLE= 0.0 DO 10 1=1,37 R= ANGLE* 3.14159/180. VX(I)=RIDUS*COS(R)+1.5 VY(I)=RIDUS*SIN(R)+1.5 ANGLE= ANGLE+10 CONTINUE RETURN END REAL CURX(38),CURY(38) REAL ROUNDX(37),ROUNDY(37) REAL POINTX( 2),POINTY( 2) REAL CUR1X(100),CUR1Y(100) REAL CUR2X(100),CUR2Y(100) REAL SIDEX( 5),SIDEY( 5) CHARACTER*4 GWF1, GWF2, GF REAL GTRAN1(2,3), GTRAN2(2,3) DATA SIDEX/ 0 , 3.00, 3.00, 0 , 0 / DATA SIDEY/ 0 , 0 , 2.00, 2.00, 0 / open GKS system GF='-ERR' OPEN(UNIT= 2 0,FILE=GF,STATUS='UNKNOWN' ) CALL GOPKS(20) CALL GOPWK(1,8,100) CALL GACWK(1) GWF1='-PLOTTE' GWF2='-T4014 ' OPEN(UNIT=14,IOSTAT=IOS,FILE=GWF1,STATUS='UNKNOWN') OPEN(UNIT=15,1OSTAT=IOS,FILE=GWF2,STATUS='UNKNOWN * ) CALL GOPWK( 2,14,100000) CALL GOPWK( 3,15,100000) set two t r a n s f o r m a t i o n s of number 1 and number 2 CALL GSWN( 1,-1.5,4.5,0.0,3.0) CALL GSVP( 1,0.0,1.0,0.5,1.0) CALL GSWN( 2,-1.0,4.0,-1.0,3.0) CALL GSVP( 2,0.0,1.0,0.0,0.5) c r e a t e the upper-half image ANGLE= 0.0 DO 10 1=1, 38 R=ANGLE* 3.14159/180. 71 CURX(I)= 0.2*(COS(R)+R*SIN(R))+1.3 CURY(I)=0.2*(SIN(R)-R*COS(R))+1.5 ANGLE= ANGLE+10. 10 CONTINUE CALL GSELNT( 1 + 1-1 ) CALL GCRSG( 1 ) R=0.2 CALL MAKER(R,ROUNDX,ROUNDY) CALL GPL(37,ROUNDX, ROUNDY) DO 20 1=1,6 R=R+0.1 CALL MAKER(R,ROUNDX,ROUNDY) CALL GPL(37,ROUNDX, ROUNDY) 20 CONTINUE CALL GCLSG CALL GCRSG( 2) CALL NUMBER(0.0,0.2999,30.0) CALL NUMBER(0.2999,0.5999,15.0) CALL NUMBER(0.5999,0.7999,4.0) CALL GCLSG CALL GCRSG( 5) CALL GPL(38,CURX, CURY) DO 30 1=1,19 CURXU )=CURX(2*I ) CURY(I)=CURY(2*1) 30 CONTINUE CALL GPM(19,CURX, CURY) CALL GCLSG CALL GCRSG( 3") CALL GSCHSP( 0.15) CALL GSCHH( 0.09) CALL GTX(0.6,2.6,'A POLAR PLOT WITH GRID') CALL GCLSG CALL GCRSG(12) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) CALL GINSG( 3,GTRAN1) CALL GEVTM(1.5,1.5,0.0,0.0, 0 ,0.5,0.7,0,GTRAN1) CALL GINSG( 5,GTRAN1) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) CALL GINSG( 1,GTRAN1) CALL GCLSG CALL GRENSG(12,10) C C c r e a t e lower-half image CALL GSELNT( 2) CALL GCRSG( 4) CALL GSCHSP( 0.2 ) CALL GSCHH( 0.1) CALL GTX(0.5,2.5,'XGRAF WITH A GRID') CALL GCLSG CALL GCRSG( 9) CALL GPL( 5,SIDEX, SIDEY) POINTX(1)=0.0 POINTY(1)=0.0 72 POINTX(2)=0.0 POINTY(2)=2.0 DO 50 1=1,10 DO 60 J=1,2 60 POINTX(J)=POINTX(J)+0.3 CALL GPL( 2,POINTX, POINTY) 50 CONTINUE POINTX(1)=0.0 POINTY(1)=0.0 POINTX(2)=3.0 POINTY(2)=0.0 DO 70 1=1,10 DO 80 J=1,2 80 POINTY(J)=POINTY(J)+0.2 CALL GPL( 2,POINTX, POINTY) 70 CONTINUE CALL GCLSG DO 90 1=1,100 X= FLOAT(I)/ 100. CUR1X(I)=X*3.0 CUR1Y(I)=EXP(-3.*X)*SIN(X*8.*3.14159)+1.0 CUR2X(I)=X*3.0 CUR2Y(I)=EXP(-3.*X)*COS(X*8.*3.14159)+!.0 90 CONTINUE CALL GCRSG( 6) CALL GPL(100,CUR1X, CUR1Y) CALL GPL(100,CUR2X, CUR2Y) CALL GCLSG CALL GCRSG( 7) CALL GSCHSP( 0.93) CALL GSCHH( 0.05) CALL GTX(-0.1,-0.2,'0.0 0.1 0.2 0.3 0.4 0.5 0.6') CALL GTX(1.96, -0.2,'0.7 0.8 0.9 1.0*) CALL GSCHSP( 0.15) CALL GSCHH( 0.08) CALL GTX(0.5,-0.5,*X AXIS WITH GRAF TYPE') CALL GCLSG CALL GCRSG( 8) CALL GSCHSP( 0.8 ) CALL GSCHH( 0.05) CALL GSCHUP(-1.0,0.0) CALL GTX(-0.1,-0.1,'-1.0 -0.6 -0.2 +0.2 +0.6 +1.0') CALL GSCHSP( 0.12) CALL GSCHH( 0.07 ) CALL GTX(-0.32,0.2,'Y AXIS WITH GRAF TYPE') CALL GCLSG CALL GCRSG(12) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) CALL GINSG( 9,GTRAN1) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) CALL GINSG( 6,GTRAN1) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) CALL GINSG( 4,GTRAN1) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) 73 C C CALL GINSG( 7,GTRAN1) CALL GEVTM(0.,0.,0.,0.,0.,1.,1.,0,GTRAN1) CALL GINSG( 8,GTRAN1) CALL GCLSG CALL GRENSG(12,11) d i s p l a y the c r e a t e d CALL GACWK( 2) CALL GCSGWK( 2,11) CALL GCSGWK( 2,10) CALL GCSGWK( 2, 2) CALL GDAWK( 2) images onto the work s t a t i o n 2 C C CALL CALL CALL CALL CALL STOP END GDAWK(1) GCLWK(1) GCLWK( 2) GCLWK( 3) GCLKS SUBROUTINE NUMBER(R1,R2,DEGREE) number the r a d i u s l i n e s between two c i r c l e s REAL PX( 2),PY( 2) REAL DEGREE 10 ANGLE= 0.0 J=360./DEGREE DO 10 I = 1 , J PX( 1 )=R1*COS(ANGLE) + 1 .5 PY(1)=R1*SIN(ANGLE)+1.5 PX(2)=R2*COS(ANGLE)+1.5 PY(2)=R2*SIN(ANGLE)+1.5 CALL GPL( 2,PX, PY) ANGLE=ANGLE+DEGREE* 3.14159/180. CONTINUE RETURN END 74 A P O L A R P L O T WITH GRID X G R A . F W I T H A G R I D I O . O O . I 0 . 2 0 . 3 O . •* 0 . 5 0 . 6 0 . 7 O . S O . 9 ' 1 . O X A X I S W I T H G R A F T Y P E { { EXAMPLE 3 IN HL/GKS } } VECTOR ROUND(37), MARKS(2), MARK VECTOR PART1(18),PART2(18), PART3(18) VECTOR PART4(18), 0UTP(18), SIDES(5), PSIDE(5),DT SEGMENT PICTURE, CENTER, PIE, PART SEGMENT TITLE, PATHS TRANS NT(3) WORKSTATION PLOTTER DATA MARKS/-1.0,0.0; 1.0,0.0/ DATA SIDES/0.0,0.0; 0.3,0.0; 0.3,0.2; 0.0,0.2; 0.0,0.0/ BEGIN {GKS} REST= 10.*3.14159/180. ANGLE= REST DO 10 1=1,37 ROUND(l)= (COS(ANGLE), SIN(ANGLE)) ANGLE= ANGLE+REST NT(1)= NT(2)= NT(3)= { CREATE THE UPPER-LEFT PORTION OF THE IMAGE } { } OPEN CENTER WITH NT(1) CENTER= POLYLINE ROUND( 1:37) CLOSE OPEN PICTURE PICTURE= POLYMARKER MARKS(1:2) + CENTER CLOSE PICTURE= PICTURE + PICTURE + PICTURE { CREATE THE LOWER-LEFT PORTION OF THE IMAGE } { } OPEN PATHS WITH NT(2) MARK= (1.0,2.0) PATHS= TEXT 'GKS' AT (1.1,2.0); 76 'GKS' AT (0.9,2.0); 'GKS' AT (1.0,2.1); 'GKS' AT (1.0,1.9) + POLYMARKER MARK CLOSE PATHS=PATHS +PATHS OPEN TITLE TITLE= TEXT 'WELCOME TO' AT (0.65,1.02) CLOSE { CREATE THE RIGHT PORTION OF THE IMAGE } { } CALL GETP(-120.-0,360.0,PARTI ) CALL GETP(0.0,70.0,PART2) CALL GETP(70.0,110.0,PART3) CALL GETP(110.0,155.0,PART4) CALL GETP(155.0,240.0,OUTP) OPEN PART WITH NT(3) CALL BLOCK(198.0,SIDES,PSIDE,DT) PART= POLYLINE 0UTP(1:18); PSIDE(1:5) + TEXT 'FOUR' AT(DT.XCOORD+0.04,DT.YCOORD+0.11); '23.6%' AT (DT.XCOORD+0.03,DT.YCOORD+0.01) CLOSE OPEN PIE PIE= FILLAREA PART1(1:18); PART2(1:18); PART3(1:18); PART4(1:18) CALL.BLOCK(3 0 0.0,SIDES,PSIDE,DT) PIE= PIE + FILLAREA PSIDE(1:5) + TEXT 'FIVE' AT (DT.XCOORD+0.04, DT.YCOORD+0.11); '33.3%' AT (DT.XCOORD+0.03, DT.YCOORD+0.01) CALL BLOCK(35.0,SIDES,PSIDE,DT) PIE= PIE + FILLAREA PSIDE(1:5) + TEXT 'ONE' AT (DT.XCOORD+0.05, DT.YCOORD+0.11); '19.4%' AT (DT.XCOORD+0.04, DT.YCOORD+0.01) CALL BLOCK(100.0,SIDES,PSIDE,DT) PIE= PIE+ FILLAREA PSIDE(l:5) + TEXT 'TWO' AT (DT.XCOORD+0.05, DT.YCOORD+0.11); '11.1%' AT (DT.XCOORD+0.04, DT.YCOORD+0.01) CALL BLOCK(145.0,SIDES,PSIDE,DT) PIE= PIE+ FILLAREA PSIDE(1:5) + TEXT 'THREE' AT (DT.XCOORD+0.03, DT.YCOORD+0.11); '12.5%' AT (DT.XCOORD+0.03, DT.YCOORD+0.01); 'PIE CHARTS' AT (-0.6,1.7); 'FIRST' AT (-0.25,1.3) CLOSE PIE= PIE+PART DISPLAY PIE ON PLOTTER DISPLAY TITLE+PATHS ON PLOTTER DISPLAY PICTURE ON PLOTTER STOP END { GET SOME PART OF A CIRCLE } { } SUBROUTINE GETP(A1,A2,POINT) VECTOR P0INTO8), DIST REAL RADIUS BEGIN IF (A1.LT.0.0) THEN A1= 360.+A1 END IF IF (A2.LT.0.0) THEN A2= 360.+A2 END IF ANGLE= A1 R1=((A2-A1)/2.+A1)*3.14159/180. DIST= (0.1*COS(R1), 0.1*SIN(R1)> POINT(1)= (DIST.XCOORD,DIST.YCOORD) POINT(18)= POINT(1) ADDING= (A2-A1)/14. DO 10 1=1,15 RADIUS= ANGLE*3.14159/180. P0INT(I+1)= (COS(RADIUS)+DIST.XCOORD, SIN(RADIUS)+DIST.YCOORD) ANGLE= ANGLE+ ADDING CONTINUE RADIUS= A2*3.14159/180. POINT(17)= (COS(RADIUS)+DIST.XCOORD, SIN(RADIUS)+DIST.YCOORD) RETURN END { GET A LABELLING BLOCK } { } SUBROUTINE BLOCK(A,VS,PS,VT) VECTOR VS(5), VT VECTOR PS(5) BEGIN A= A*3.14159/180. VT= (0.7*COS(A), 0.7*SIN(A)) DO 10 1=1,5 PS(I)= (VS.XCOORD(I)+VT.XCOORD, VS.YCOORD(I)+VT.YCOORD) CONTINUE RETURN END <9 P J t f CHARTS f lPIT -J 80 { } { Example 4 i n HL/GKS } { } SEGMENT STAR(2) ,STARS(2),FLAG(2) ,FLAGS(2),NAME(2) , TITLE VECTOR POINT(11), SIDE1(5), DIST,OUT(5), IN(5), LEAF(26), SIDE2(5), PART1(5), PART2(5) TRANS NT(3) WORKSTATION PLOTTER, T4010 DATA SIDE1/1.0,3.0; 4.0,3.0; 4.0,5.0; 1.0,5.0; 1.0,3.0/ DATA OUT/1.0,2.0; 0.0,1.3; 0.41,0.2; 1.61,0.2; 1.9,1.3/, IN/0.8,1.35; 0.65,0.9; 1.0,0.65; 1.38,0.9; 1.25,1.35/ DATA SIDE2/0.0,0.0; 6.0,0.0; 6.0,3.0; 0.0,3.0; 0.0,0.0/ DATA LEAF/3.0,2.5; 2.8,2.0; 2.6,2.2; 2.9,1.5; 2.25,1.75; 2.3,1.5; 1.9,1.4; 2.3,1.3; 2.15,1.05; 2.9,1.2; 2.5,0.8; 2.9,1.0; 2.9,0.2; 3.1,0.2; 3.1,1.0; 3.5,0.8; 3.1,1.2; 3.85,1.05; 3.7,1.3; 4.2,1.4; 3.7,1.5; 3.8,1.7; 3.1,1.5; 3.4,2.2; 3.2,2.0; 3.0,2.5/, PART1/0.0,0.0; 1.5,0.0; 1.5,3.0; 0.0,3.0; 0.0,0.0/ BEGIN { GKS i n i t i a l i s a t i o n } { set t r a n s f o r m a t i o n s } NT(1)= NT(2)= NT(3)= { c r e a t e Chinese n a t i o n a l f l a g s onto the } { r i g h t - h a l f plane of the output image } DO 10 1=1,5 J=(2*I)-1 K=2*I P0INT(J)= OUT(I) POINT(K)= IN(I) 10 CONTINUE POINT(11)= POINT(1) { c r e a t e the c e n t r e Chinese f l a g } OPEN STARO) WITH NT(1) STAR(1)= FILLAREA POINT(1:11) CLOSE STAR(1)= STAR(1) STAR(2)= STAR(1) STARS(1)= STARd) STARS(2)= STARS(1) STARd )= STARd) OPEN FLAG(1) FLAG(1)= FILLAREA SIDE1(1:5) + TEXT 'CHINA' AT (1.4,2.2) + STAR(1) CLOSE FLAGS(1)= FLAG(1) R= 0.65 DIST= (R*COS(10.*3.14159/180.)+0.6, R*SIN(10.*3.14159/180.)+3.5) STAR(2)= STAR(2) STAR(2)= STAR(2)+ STAR(2) + STAR(2) + STAR(2) FLAG(1)= FLAG(1)+ STAR(2) { c r e a t e the surrounding Chinese f l a g s } R= 0.24 DIST= (R*COS(10.*3.14159/180.)+0.6, R*SIN(10.*3.14159/180.)+3.5) STARS(2)= STARS(2) + STARS(2) + STARS(2) FLAGS(1)= FLAGS(1)+ STARS(2) R=4.5 DIST=(R*COS(260.0*3.14159/180.)+1.5, R*SIN(260.0*3.14159/180.)+0.5) FLAGS(1)= FLAGS(1) 82 +FLAGSO) +FLAGSO) { c r e a t e the t i t l e of the output image } OPEN TITLE WITH NT(3) TITLE= TEXT 'FRIENDSHIP' AT (0.15,0.1); 'OF' AT (0.38,0.0) CLOSE { c r e a t e Canadian n a t i o n a l f l a g s onto the } { l e f t - h a l f plane of the output image } DO 50 1=1,5 PART2(I)= (PART1 .XCOORD(I)+ 4.5, PART1 .YCOORD(I)) 50 CONTINUE { c r e a t e the c e n t r e Canadian f l a g } OPEN FLAG(2) WITH NT(2) FLAG(2)= POLYLINE SIDE2(1:5) + FILLAREA LEAF(1:26); PART1(1:5); PART2(1:5) CLOSE OPEN NAME(1) NAME(1)= TEXT 'CANADA' AT (0.0,0.0) CLOSE OPEN NAME(2) NAME(2)= TEXT 'CANADA' AT (0.0,0.0) CLOSE { c r e a t e the surrounding Canadian f l a g } FLAGS(2)= FLAG(2) + NAME(2) FLAG(2)= FLAG(2) + NAME(1) FLAGS(2)= FLAGS(2) + FLAGS(2) + FLAGS(2) DISPLAY FLAG(2), FLAGS(2) ON PLOTTER DISPLAY FLAG(1)+ FLAGS(1), TITLE ON PLOTTER STOP END 85 VI. CONCLUSION AND PROPOSALS As an extended language, a number of syntax and semantics r u l e s , based on the GKS system, are supplemented i n the g r a p h i c a l l y o r i e n t e d extension of HL/GKS. The two kinds of statements, the host language FORTRAN 77 statements and the g r a p h i c a l extension statements of HL/GKS, can be f r e e l y i n t e r s p e r s e d i n an HL/GKS program, p r o v i d i n g f u l l g r a p h i c a l and nong r a p h i c a l support. Some examples of i n t e r s p e r s e d statements are presented i n F i g u r e 45. REAL r1, r2 VECTOR vg, vt(2) SEGMENT house DATA r1/1.3/, vt/0.0,0.0; 1.0,1.5/, r2/2.0/ vg = (1.5, 2.8*sin(0.2)) vg = (r1, r2) OPEN house {any FORTRAN statements} house = POLYLINE s i d e d : 10) {any FORTRAN statemets} house = house +TEXT 'welcome to GKS' AT vg {any FORTRAN statements} CLOSE DO 10 i = 1,15 {any g r a p h i c a l statements} k= k + i vg = (vg.xcoord+i, vg.ycoord+k) house = house + house {any FORTRAN statements} 10 CONTINUE F i g u r e 45 - Some I n t e r p o s i n g Instances i n HL/GKS The precompiler i s not case s e n s i t i v e as to keywords and v a r i a b l e s , i . e . , upper and lower case c h a r a c t e r s may be used. The programming s t r u c t u r e s WHILE and REPEAT bl o c k s and a f r e e layout of statements have been i n t r o d u c e d i n HL/GKS. Moreover, blank l i n e s and f r e e l y - p l a c e d comments w i t h i n the braces "{" and 86 "}" are allowed. Modular programming i s a v a i l a b l e with the p o s s i b i l i t y of pr e c o m p i l i n g p a r t s of a program. More reasonable and understandable language p a t t e r n s compared to the subroutine i n v o c a t i o n s of GKS render HL/GKS a p p e a l i n g f o r both l e a r n i n g and u t i l i z i n g the system. The s t a t e r e s t r i c t i o n s of GKS and many system s p e c i f i c a t i o n s are s i m p l i f i e d i n HL/GKS, they are b a s i c a l l y c o n t r o l l e d and generated by the prec o m p i l e r . In GKS, the segment t r a n s f o r m a t i o n order i s p r e d e f i n e d and f i x e d to the order of s c a l i n g , r o t a t i o n and t r a n s l a t i o n . For any other order, i t i s the r e s p o n s i b i l i t y of the programmer to accumulate the t r a n s f o r m a t i o n s i n the order d e s i r e d one by one i n t o an a p p r o p r i a t e t r a n s f o r m a t i o n matrix. CALL GEVTM(x 0,y 0,dx,dy,ph i , f x,f y,sw,mout) CALL GACTM(mout,x0,y0,dx,dy,phi,fx,fy,sw,mall) The d e c l a r a t i o n and s e t t i n g of the ev a l u a t e and accumulate matrices f o r d i f f e r e n t l y ordered t r a n s f o r m a t i o n s are a l s o the programmer's r e s p o n s i b i l i t y . In c o n t r a s t , a p a t t e r n of t r a n s f o r m a t i o n s i s a p p l i e d i n HL/GKS i n s t e a d of the matrix assignment of GKS. The keywords i n a t r a n s f o r m a t i o n p a t t e r n r e f e r to the i n d i v i d u a l t r a n s f o r m a t i o n steps and the order of the keywords i s s i g n i f i c a n t . The c h a r a c t e r D appended t o the r o t a t i o n angle means that i t i s measured by degrees i n s t e a d of r a d i a n s . A comparison of segment t r a n s f o r m a t i o n s i n the order of t r a n s l a t i o n , r o t a t i o n , and s c a l i n g , i n HL/GKS and GKS, i s given i n F i g u r e 46. The b a s i c p i c t u r e e n t i t y of GKS, the segment, i s only s i n g l e - l e v e l s t r u c t u r e d . No access i s p o s s i b l e to the elements 87 house < AT: atv, SHIFT: shv, ROT: ra D, SCALE: scv > REAL t r a n l ( 2 , 3 ) , tran2(2,3) r1 = ra *(3.14159/180.) CALL GEVTM(atvx,atvy,shvx,shvy,0.,1.,1.,0,tranl) CALL GACTM(tran1,0.,0.,0.,0.,r1,1.,1.,0,tran2). CALL GACTM(tran2,0.,0.,0.,0.,0.,scvx,scvy,0,tran1) CALL GSSGT(3,tran1) F i g u r e 46 - An A r b i t r a r i l y Ordered Segment Tansformation i n Both Languages of a compounded segment. A segment can not be updated a f t e r i t has been c r e a t e d . In a d d i t i o n , most segment o p e r a t i o n s are r e s t r i c t e d to the system s t a t e bounds. For example, the i n s e r t i o n segments i n t o an open segment must occur i n the s t a t e of "at most one segment open" with the a d d i t i o n a l c o n d i t i o n that there are segments . i n WISS (workstation independent segment s t o r a g e ) . In HL/GKS, with the data type SEGMENT s u p p l i e d , a h i e r a r c h i c a l m o d e l l i n g f a c i l i t y f o r segments has been p r o v i d e d . A segment can be superimposed or updated with any element a f t e r i t has been c r e a t e d . M u l t i p l e m o d e l l i n g of a segment i s a v a i l a b l e by a l l o w i n g a r e f e r e n c e to i t s e l f ; segment r e d e f i n i t i o n i s a l s o p o s s i b l e by r e f e r r i n g t o other segments. Some i n s t a n c e s of segment mod e l l i n g are presented i n F i g u r e 47. house = house + door < AT:(4.0,5.2)> + window(l) + roof house = house - window(1) + window(2) house = b u i l d i n g + t r e e F i g u r e 47 - Segment M o d e l l i n g i n HL/GKS No s t a t e r e s t r i c t i o n s of GKS are imposed by the segment o p e r a t i o n s of HL/GKS except the s t a t e of "at most one segment 88 open" which i s pro v i d e d by the statement p a i r of segment open and c l o s e . The two a t t r i b u t e assignment modes of GKS, bundled and i n d i v i d u a l , are i n t e r n a l l y f l a g g e d and assigned to a bundle t a b l e only by the keyword TABLE or to i n d i v i d u a l by keywords i n the a t t r i b u t e assignment. No r e s t r i c t i o n s have been p l a c e d on the assignment modes pr o v i d e d . The s t a t e s of "GKS open", "GKS c l o s e d " , "at l e a s t one workstation open", and "at l e a s t one works t a t i o n a c t i v e " are a l l tr a n s p a r e n t to the HL/GKS programmer. The f u n c t i o n r e s t r i c t i o n s on the s t a t e s of GKS have been reduced by the c l a r i f i e d syntax and semantics of HL/GKS. Most s p e c i f i c a t i o n s of GKS system are c o l l e c t e d as a t t r i b u t e groups to be assign e d to a r e l a t e d data type, thus p r o v i d i n g the concept of f u n c t i o n a l performance i n s t e a d of i n d i v i d u a l i n v o c a t i o n s of subrout i n e s i n GKS. The syntax design of HL/GKS keeps the form f o r i t s statements c o n s i s t e n t with the host language FORTRAN 77, e.g., d e c l a r a t i o n , assignment, and input statements. The semantics of HL/GKS have been kept as c l o s e as p o s s i b l e to the d e f i n i t i o n of GKS. Most keywords used i n HL/GKS are d i r e c t l y i n f e r r e d from the corresponding d e f i n i t i o n s of the GKS document, p r o v i d i n g a n a t u r a l meaning f o r each. The works t a t i o n types of a c o n f i g u r a t i o n are p r e d e f i n e d i n the precompiler f o r proper r e f e r e n c e of the wo r k s t a t i o n s . The viewing p i p e l i n e of GKS i s r e f l e c t e d i n d e f i n i t i o n s of HL/GKS. M u l t i p l e assignment of segments and workstations i n a d i s p l a y statement i s parsed to m u l t i p l e output of segments onto s e v e r a l d i s p l a y workstations s i m u l t a n e o u s l y . Output p r i m i t i v e s 89 are i n c l u d e d i n the output streams of HL/GKS, as f o r the GKS d e f i n i t i o n . The concept of m u l t i p l e assignment i s a l s o a p p l i c a b l e to p r i m i t i v e m o d e l l i n g , s i m p l i f y i n g m u l t i p l e p r i m i t i v e assignment with an i d e n t i c a l p r i m i t i v e type. The o v e r l o a d i n g of numerical parameter assignments of segments, t r a n s f o r m a t i o n s , and a t t r i b u t e s of GKS has been removed by the use of name r e f e r e n c e s of the parameters. G r a p h i c a l parameters may appear i n a subroutine formal parameter l i s t , opening the g r a p h i c a l communications among main program and s u b r o u t i n e s , which f a c i l i t a t e s the g r a p h i c a l p r o c e s s i n g to each g l o b a l and l o c a l f u n c t i o n . The main disadvantage of the HL/GKS implementation i s due to the e x t r a storage space r e q u i r e d f o r the precompiler and the a d d i t i o n a l e x ecution time r e q u i r e d f o r the p r e c o m p i l i n g . The shortcoming w i l l become l e s s important with the development of a GKS c h i p and the p o p u l a r i t y of GKS a p p l i c a t i o n s . Stemming from the experience with the HL/GKS implementation, s e v e r a l suggestions and p r o p o s a l s f o r f u r t h e r development of HL/GKS are o f f e r e d as f o l l o w s : extending HL/GKS f o r thr e e - d i m e n s i o n a l g r a p h i c s , e i t h e r based on the f u n c t i o n a l mapping of the three-d i m e n s i o n a l GKS ISO d r a f t or by the development of new system r o u t i n e s to be i n c l u d e d i n i t s runtime l i b r a r y . supplementing the set of output p r i m i t i v e s , e.g., by square and c i r c l e , using the same assignment r u l e s as the p r i m i t i v e s of HL/GKS. The parameters of a new p r i m i t i v e type 90 can be assig n e d with the same syntax as f o r p r i m i t i v e a t t r i b u t e s while the new p r i m i t i v e i s named with an a p p r o p r i a t e keyword. For example, the p r i m i t i v e c i r c l e may be s p e c i f i e d as: CIRCLE l e f t adding more p r a c t i c a l f u n c t i o n s to the runtime l i b r a r y of HL/GKS, such as a comparison of two segments e q s e g ( f 1 , f 2 : segment), or t e s t f o r presence of a v e c t o r i n a segment member(v:vector; f:segment), e t c . , to f a c i l i t a t e implementation of g r a p h i c a l a l g o r i t h m s . extending the s y n t a c t i c and semantic d e f i n i t i o n s of HL/GKS to other GKS l e v e l s , as f o r in s t a n c e adding the input modes sample and event of GKS, to the GKS l e v e l 2C. With the development of GKS c h i p s and an i n c r e a s i n g p o p u l a r i t y of the GKS standard, the c h a r a c t e r i s t i c s of the h i g h -l e v e l g r a p h i c s language HL/GKS w i l l become a t t r a c t i v e and s i g n i f i c a n t , as i t promises higher p r o d u c t i v i t y of programmers and i n c r e a s e d e f f i c i e n c y of GKS a p p l i c a t i o n programs. 91 REFERENCES [Bart82] W. Barth, J . Di r n b e r g e r , and W. Purgathofer, "The High-L e v e l Graphics Programming Language PASCAL/GRAPH," Computer and Graphics, V o l . 6, No. 3, 1982, pp. 109-119. [ B r a c 7 l ] G. B r a c c h i and D. F e r r a r i , "A Language f o r T r e a t i n g Geometric P a t t e r n s i n a Two-Dimensional Space," Communications of the ACM, V o l . 14, No. 1, January 1971, pp. 26-32. [Brie75] C D . O'Brien and H.G. Bown, "IMAGE: A Language f o r the I n t e r a c t i v e M a n i p u l a t i o n of a Graphics Environment," Computer Graphics, ACM-Siggraph, June 1975, pp. 53-60. [Dene75] E. Denert, G. E r n s t , and H. Wetzel, "GRAPHEX68: G r a p h i c a l Language Features i n ALGOL 68," Computer and Grap h i c s , V o l . 1, 1975, pp. 195-202. [East77] C. Eastman and M. Henrion, " G l i d e : A Language f o r Design Information Systems," Computer and Gra p h i c s , 1977, pp. 24-33. [Ende84] G. E n d e r l e , K. Kansy and G. P f a f f , Computer Graphics Programming, GKS The Graphics Standard, S p r i n g e r -V e r l a g , B e r l i n H e i d e l b e r g , 1984. [Guib82] L . J . Guibas and J . S t o l f i , "A Language f o r Bitmap M a n i p u l a t i o n , " ACM T r a n s a c t i o n s on Graphics, V o l . 1, No. 3, J u l y 1982, pp. 191-214. [Magn8l] N. Magnenat-Thalmann and D. Thalmann, "A G r a p h i c a l PASCAL Exte n s i o n Based on G r a p h i c a l Types," Software P r a c t i c e and Experience, V o l . 11, 1981, pp.53-62. [Mair84] S.G. Mair, UBC GKS, Computing Centre, The U n i v e r s i t y of B r i t i s h Columbia, 1984. [Ross82] R. Ross, LIG6 User's Manual, Department of E l e c t r i c a l E n g i n e e r i n g , The U n i v e r s i t y of B r i t i s h Columbia, 1982. [Schr82] G.F. Schrack, G. Cheng, H. Leung and B. Yu, CWS-TD User's Manual, Department of E l e c t r i c a l E n g i n e e r i n g , The U n i v e r s i t y of B r i t i s h Columbia, A p r i l 1982. [Shap75] L.G. Shapiro, "ESP 3: A H i g h - l e v e l Graphics Language," Computer Graphics, V o l . 9, No. 1, 1975, pp. 70-77. [Sm i t 7 l ] D.N. Smith, "GPL/I A PL/I Extension f o r Computer G r a p h i c s , " Spring J o i n t Computer Conference, 1971, pp. 511-528. 92 BIBLIOGRAPHY [Aho 77] A.V. Aho and J.H. Ullman, P r i n c i p l e s of Compiler Design, Addison-Wesley, 1977. [Aho 72] A.V. Aho and J.H. Ullman, The Theory of P a r s i n g , T r a n s l a t i o n and Compiling, P r e n t i c e - H a l l , 1972. [Back79] R. Backhouse, Syntax of Programming Languages, P r e n t i c e - H a l l , 1979. [Berg76] S. Bergman and A. Kaufman, "BGRAF2: A Real-Time Graphics Language With Modular Objects and I m p l i c i t Dynamics," Computer Graphics ACM, Siggraph'76, V o l . 10, No. 2, 1976, pp. 133-138. [Bono82] P.R. Bono, J.L. Encarnacao, F.R.A. Hopgood and P.J.W. ten Hagen, "GKS The F i r s t Graphics Standard," IEEE Computer Graphics and A p p l i c a t i o n s , J u l y 1982, pp. 9-22. [Burk68] W.H. Burkhardt, "Metalanguage and Syntax S p e c i f i c a t i o n , " Communications of the ACM, V o l . 8, No. 5, 1965, pp. 304-306. [ C l a r 8 l ] D.R. C l a r k , Computers f o r Imagemaking, Pergamon Press, London, 1981. [Enca8l] J.L. Encarnacao, Ed., Eurographics '81, North-Holland, N.Y.,1981. [Fole82] J.D. F o l e y and A. van Dam, Fundamentals of I n t e r a c t i v e Computer Graphics, Addison-Wesley, 1982. [Fole76] J.D. F o l e y , " P i c t u r e Naming and M o d i f i c a t i o n : An Overview," Proceedings ACM Symposium on Graphic Languages, Computer Graphics, V o l . 10, NO. 1, 1976, pp. 49-53. [Gilo74] W.K. G i l o i and J . Encarnacao, "APLG - An APL based System f o r I n t e r a c t i v e Computer G r a p h i c s , " AFIPS Conference Proceedings, V o l . 43, 1974, pp. 521-528. [Gilo78] W.K. G i l o i , I n t e r a c t i v e Computer Gr a p h i c s , P r e n t i c e -H a l l , Englewood C l i f f s , N.J., 1978. [Goos76] G. Goos and J . Hartmanis, Design and Implementation of Programming Languages, L e c t u r e Notes i n Computer Science 54, Ithaca, N.Y., 1976. [ G r i f 7 6 ] M. G r i f f i t h s , "LL(1) Grammars and A n a l y s e r s , Compiler C o n s t r u c t i o n - An Advanced Course," L e c t u r e Notes i n Computer Science 21, S p r i n g e r - V e r l a g , 1977. [Harr84] D. H a r r i s , Computer Gra p h i c s and A p p l i c a t i o n s , Chapman 93 and H a l l , N.Y., 1984. [Hurw67] A. Hurwitz and J.P. C i t r o n , "GRAF: Graphic A d d i t i o n s to FORTRAN," Spring J o i n t Computer Conference, 1967, pp. 553-557. [Jone76] B. Jones, "An Extended ALGOL-60 f o r Shaded Computer Gr a p h i c s , " Proceedings ACM Symposium on Graphic Languages, Computer Graphics, V o l . 10, No. 1, 1976, pp. 18-23. [Krig76] M.P. K r i g e r , "SUGER: A High-Level Programming Language fo r G eographical A n a l y s i s , " Proceedings ACM Symposium on Graphic Languages, Computer Gr a p h i c s , V o l . 10, No. 1, 1976, pp. 40-47. [Lieb76] H. Lieberman, "The TV T u r t l e : A Logo Grap h i c s System fo r Raster D i s p l a y s , " Proceedings ACM Symposium on Graphic Languages, Computer G r a p h i c s , V o l . 10, No. 1, 1976, pp. 66-72. [Luci76] A.P. Lucido, "Software Systems For Computer Graphics," Computer, V o l . 9, No. 2, August 1976, pp. 23-32. [Magn85] N. Magnenat-Thalmann, D. Thalmann and M . F o r t i n , "Miranim: An E x t e n s i b l e D i r e c t o r - O r i e n t e d System f o r the Animation of R e a l i s t i c Images," IEEE Computer Graphics and A p p l i c a t i o n s , March 1985, pp. 61-73. [Mall82] W.R. M a l l g r e n , "Formal S p e c i f i c a t i o n of Graphic Data Types," T r a n s a c t i o n s on Programming Languages and Systems, V o l . 4, No. 4, October 1982, pp. 687-710. [Mell84] M.E. M e l l and S.J. N o l l , " S p e c i a l F e a t u r e : A VLSI Support f o r GKS," IEEE Computer Graphics and A p p l i c a t i o n s , August 1984, pp. 52-55. [Newm7l] W.M. Newman, " D i s p l a y Procedures," Communications ACM, V o l . 14, No. 10, Oct. 1971, pp. 651-660. [Newm73] W.M. Newman and R.F. S p r o u l l , P r i n c i p l e s of I n t e r a c t i v e Computer Graphics, McGraw H i l l , N.Y., 1973. [Orga78] E . I . Organick, A.I. Forsythe and R.P. Plummer, Programming Language S t r u c t u r e s , Academic P r e s s , N.Y., 1978. [Osla84] C D . Osland, "Case study of GKS Development," Eurographics T u t o r i a l s ' 8 3 , S p r i n g e r - V e r l a g , 1984, pp. 264-289. [Paga8l] F.G. Pagan, Formal S p e c i f i c a t i o n of Programming Languages, P r e n t i c e - H a l l , 1981. [ P f i s 7 6 ] G.F. P f i s t e r , "A High L e v e l Language E x t e n s i o n f o r 94 C r e a t i n g and C o n t r o l l i n g Dynamic P i c t u r e s , " Proceedings ACM Symposium on Graphic languages, Computer Gr a p h i c s , V o l . 10, No. 1, 1976, pp. 1-9. [Rubi84] R.V. Rubin and J.N. Pato, "MFE: A Syntax D i r e c t e d E d i t o r f o r I n t e r a c t i o n S p e c i f i c a t i o n , " Graphics I n t e r f a c e ' 8 4 , 1984, pp. 265-269. [Ruda84] M. R u d a l i c s , "Dynamic A t t r i b u t e s Handling on a GKS Workstation," Graphics I n t e r f a c e ' 8 4 , 1984, pp. 81-86. [Scho84] J . Schonhut, "The G r a p h i c a l Kernel System," Eurographics T u t o r i a l s ' 8 3 , S p r i n g e r - V e r l a g , 1984, pp. 233-257. [Schr80] G.F. Schrack, " M o d e l l i n g and D i s p l a y Concepts i n a High-Level Programming Language," Eurographics'80, North-H o l l a n d , 1980, pp. 225-236. [Schr76] G.F. Schrack, "Design, Implementation and Experiences with a Hi g h e r - L e v e l Graphics Language f o r I n t e r a c t i v e Computer-Aided Design Purposes," Proceedings ACM Symposium on Graphic Languages, Computer Graphics, V o l . 10, No. 1, 1976, pp. 10-17. [Shaw83] M. Shaw, E. B o r i s o n , M. Horowitz, T. Lane, D. N i c h o l s , and R. Pausch, "Descartes: A Programming-Language Approach to I n t e r a c t i v e D i s p l a y I n t e r f a c e s , " SIGPLAN Proceedings on Programming Language Issues i n Software Systems, V o l . 18, No. 6, June 1983. [Tekt84] G r a p h i c a l Kernel System (GKS), TEK User Manual, T e k t r o n i x , Inc., May 1984. [Tuck84] H.A. Tucker and K. Bo, Eds., Eurographics'84, North-H o l l a n d , N.Y., 1984. [Vanw82] C.J. van Wyk, "A High-Level Language f o r S p e c i f y i n g P i c t u r e s , " ACM T r a n s a c t i o n s on Gra p h i c s , V o l . 1, No. 2, A p r i l 1982, pp. 163-182. [Wang76] P.S. Wang and W.I. Grosky, "A Language f o r Two-Dimensional D i g i t a l P i c t u r e P r o c e s s i n g , " Proceedings ACM Symposium on Graphic Languages, Computer Graphics, V o l . 10, No. 1, 1976, pp. 106-112. [Wyvi77] B.L.M. W y v i l l , " P i c t u r e s - 6 8 MKI," Software P r a c t i c e and Experience, V o l . 7, 1977, pp. 251-261. APPENDIX A - SYNTAX IN BACKUS-NAUR FORM ::= {
| }!
::= {} 0 BEGIN STOP END ::= < I d e n t i f i e r > { , < I d e n t i f i e r > } 0 | DATA < I d e n t i f i e r > / { ; } 0 / ::= VECTOR SEGMENT TRANS WORKSTATION ::= { | } 1 4 ::= 0 | < F i r s t Int> < F i r s t Int>::= = 1 2 3 4 5 6 7 8 9 ::= a b c d e f g h i J k o P q r s t u V w X y A B c D E F G H I J K 0 P Q R S T U V W X Y m | n M| N ::= ( ) | ::= < F i r s t Int> { } 0 ::= +| -| ::= . {}! ::= , ::= }, ::= OPEN < I d e n t i f i e r > { { ABOVE 96 |BELOW } < I d e n t i f i e r > | } }^ CLOSE ::= WITH { < I d e n t i f i e r > | } | ::= < { FROM TO ::= < I d e n t i f i e r > | ( , ) ::= CALL | WHILE ( ) DO ENDWHILE | REPEAT UNTIL ( ) CLIPPING ON CLIPPING OFF < I d n e t i f i e r > ( } ) ::= | ::= { { +| - } } 0 ::= { { *| /| . } } 0 ::= < I d e n t i f i e r > ( ) ::= < { AT: SHIFT: ROT: { { D| } | < I d e n t i f i e r > } SCALE: ) i > ::= 97 ::= POLYLINE < I d e n t i f i e r > ( ) { ; < I d e n t i f i e r > ( ) } 0 | POLYMARKER < I d e n t i f i e r > { ( ) | } { ; < I d e n t i f i e r > { ( ) | } } 0 | TEXT AT { ; AT } 0 | FILLAREA < F i l l a A t t r i > < I d e n t i f i e r > ( ) { ; < F i l l a A t t r i > < I d e n t i f i e r > ( ) } 0 | CELLARRAY < I d e n t i f i e r > ( , ) { ; < I d e n t i f i e r > ( , ) } 0 ::= TYPE : { I < I d n e n t i f i e r > } ::= COLOUR : : = < : { | < I d e n t i f i e r > } TABLE : { |} , H > : : = < { FONT : { | < I d e n t i f i e r > } PREC : { | < I d e n t i f i e r > } EXP : { | < I d e n t i f i e r > } SPACE : { | < I d e n t i f i e r > } HEIGHT : { | < I d e n t i f i e r > } UPVEC : ( , ) PATH : { | < I d e n t i f i e r > } ALIGN : { I < I d e n t i f i e r > } 98 TABLE : { |} I , } , > | < F i l l a A t t r i > : : = < { INSIDE : { | < I d e n t i f i e r > } { = { PSIZE: ( , ) | PREF: ( , ) }i )o | STYLE : { | < I d e n t i f i e r > } TABLE : { |} I , ) , > : : = < RANGE : ; MAXROW : ::= 1 { }, 1 ::= < I d e n t i f i e r > { ( { < I d e n t i f i e r > } { , { < I d e n t i f i e r > } } 0 ) | } ::= RENAME < I d e n t i f i e r > AS < I d e n t i f i e r > | DELETE < I d e n t i f i e r > { , < I d e n t i f i e r > } 0 { FROM < I d e n t i f i e r > { , < I d e n t i f i e r > } 0 | } ::= REDRAW < I d e n t i f i e r > { , < I d e n t i f i e r > } 0 ::= MESSAGE ON < I d e n t i f i e r > { , < I d e n t i f i e r > } 0 : : = < { VISIBLE | INVISIBLE 99 HIGHLIGHT NORMAL , }, | ::= READ ( { < I d e n t i f i e r > | } < I d e n t i f i e r > ) < I d e n t i f i e r > { ( { | < I d e n t i f i e r > } ) | } { , < I d e n t i f i e r > { ( { | < I d e n t i f i e r > } ) | } } 0 ::= SEND A t t r i > i f i e r > A t t r i > } 0 ier> i f i e r > } 0 < I d e n t i f i e r > } + } { < I d e n t i f i e r > | } } 0 i f i e r > < I d e n t i f i e r > } 0 ::= ERASE < I d e n t i f i e r > { , < I d e n t i f i e r > } 0 ::= { SUBROUTINE | FUNCTION } < I d e n t i f i e r > { ( < I d n e t i f i e r > { : OPEN | } { , < I d e n t i f i e r > { : OPEN |} } 0 ). | } { } 0 BEGIN RETURN END ::= CHARACTER { * | } COMPLEX DOUBLE PRECISION INTEGER LOGICAL REAL 1 00 APPENDIX B - RESERVED WORDS AND SYMBOLS For HL/GKS, as an extended language, there are g r a p h i c a l symbols and reserved keywords which are part of the syntax d e f i n i t i o n . The complete set are shown i n the two t a b l e s below. G r a p h i c a l Symbols ( : ) * / > Reserved Keywords BEGIN OPEN VECTOR SEGMENT TRANS WORKSTATION CLOSE RENAME AS DELETE FROM SEND TO DISPLAY ON CLIPPING OFF DO WHILE REPEAT ENDWHILE UNTIL WITH MESSAGE ABOVE BELOW ERASE REDRAW AT SHIFT ROT D SCALE POLYLINE TEXT POLYMARKER FILLAREA CELLARRAY VISIBLE INVISIBLE NORMAL HIGHLIGHT COLOUR TYPE TABLE FONT PREC EXP SPACE HEIGHT UPVEC PATH ALIGN INSIDE PSIZE PREF STYLE RANGE MAXROW 101 APPENDIX C - EXECUTION INSTRUCTIONS As fo r the i n s t a l l a t i o n of GKS FORTRAN b i n d i n g i n UBC, a l l workstation outputs are a s s i g n e d to i n d i v i d u a l output m e t a f i l e s , which are then t r a n s l a t e d i n t o the g r a p h i c a l f i l e of each t e r m i n a l by p o s t - p r o c e s s o r s . The name of each output m e t a f i l e i s the f i r s t s i x c h a r a c t e r s of the t r a n s l a t e d workstation name, beginning with the minus s i g n as a temporary output f i l e . For i n s t a n c e , the m e t a f i l e name of the workstation screen w i l l be the name -SCREEN. There are three m e t a f i l e p o s t - p r o c e s s o r s ( f o r the T e k t r o n i x 4027, P r i n t r o n i x p r i n t e r , and p l o t f i l e ) a v a i l a b l e to view the m e t a f i l e output from GKS. A d e t a i l e d d e s c r i p t i o n of m e t a f i l e p o s t - p r o c e s s o r s i s p r o v i d e d i n the write-up UBC GKS[Mair84], HL/GKS programs can be i n t e r a c t i v e l y executed by b u i l t - i n macros. An example of HL/GKS i n t e r a c t i v e e x ecution i s shown below where the lower-case l i n e s represent the prompts of a t e r m i n a l while the upper-case ones are the input s t r i n g s of a user. $HLGKS go1 $r HL:GKS go2 $r FORTRANVS go3 $r -fort+GKS:GKS "give the step name. G01 "give the name of your f i l e . TEST next step i s go2. "do you want to continue? Yes next step i s go3. "do you want to continue? YES $ A r b i t a r y entrance to the execution steps can be s e l e c t e d by the input of G01, Go2, or Go3 r e s p e c t i v e l y . Freedom of continuous p r o c e s s i n g i s p r o v i d e d with the i n q u i r y prompt (do you want to continue?) which can be r e p l i e d to with Y, YES, OK, N, or NO. Any e r r o r i n t y p i n g causes a r e t u r n with some warning in f o r m a t i o n p r o v i d e d . An example of s i n g l e e x ecution of step G02 i s given below. $HLGKS go1 $r HL:GKS go2 $r FORTRANVS go3 $r -fort+GKS:GKS "give the step name. G02 next s t e p i s go3. "do you want to continue? NO $ The running i n s t r u c t i o n s of the p o s t - p r o c e s s o r s a r e : 1 02 ( t r a n s l a t i o n to T e k t r o n i x ) $run GKS:Metint427 scards=metafile, ( t r a n s l a t i o n to p r i n t r o n i x p r i n t e r ) $run GKStMetintptx s c a r d s = m e a t f i l e , ( t r a n s l a t i o n to p l o t f i l e ) $run GKS:Metintplt s c a r d s = m e t a f i l e . For d e t a i l e d running s t e p s , r e f e r to the write-up of UBC GKS[Mair84]. 103 APPENDIX D - A SAMPLE OF GKS OBJECT CODE C T h i s i s a sample C preprocessor C REAL GV1X( REAL GV2X( REAL GV3X( REAL GV4X( REAL GVX, of GKS codes produced by the HL/GKS 5),GV1Y( 5),GV2Y( 5),GV3Y( 7),GV4Y( GVY 5) 5) 5) 7) CHARACTER*4 GWF1 CHARACTER*4 GWF2 REAL GTRAN1(2,3), GTRAN2(2,3) INTEGER GP0LYLO3) ,GP0LYM(13) INTEGER GTEXT(13),GFILL(13),GG(13) CHARACTER*4 GF REAL GAX(100),GAY(100) INTEGER GT,GN,GSTAT DATA DATA DATA DATA DATA DATA , 0 DATA , 0 GV1X/ GV1 Y/ 1/2/ GV2X/ GV2Y/ GV4X/ / GV4Y/ / 0, 0 50, 20, 0.70, , 0 , 5.00, 0. 0, 0, 0, 5, 70, 50, 50, 50, 00, 0, 0, 0 0, 2, 20, 50, 50, 50, 0 0 / / 0.20/ / 3.20, 4.00, 3.20, 0 C C GKS-system i n i t i a l i z a t i o n DATA GPOLYL/0,0,0,1, DATA DATA DATA DATA GPOLYM/1 GTEXT /1 GFILL /1 GG /1 1,0,0 1.1.1 1 0 1,1.1.1.1 , 1 , 1 , 1 , 1 , 1 1 ,1 ,1 ,1 ,1,1 1/ 1/ 1 ,0,0,0,0,1,1,1/ 1,1,1,1,1,0,0,0/ 1,1,1,1,1,1,1,1/ GF='-ERR' OPEN(UNIT= 2 0,FILE=GF,STATUS='UNKNOWN' ) CALL GOPKS(20) CALL GOPWK(1,8,100) CALL GACWK(1) GWF1='-PLOTTE' OPEN(UNIT=14,IOSTAT=IOS,FILE=GWF1 CALL GOPWK( 2,14,100000) GWF2='-SCREEN' OPEN(UNIT=15,1OSTAT=IOS,FILE=GWF 2,STATUS='UNKNOWN' ) CALL GOPWK( 3,15,100000) GMSG( 3,'WELCOME TO GKS' ) 1,0.0,5.0,0.0,7.0) 1,0.0,0.45,0.2,1.0) 2,1.5,3.5,0.0,7.0) 2,0.75,0.85,0.2,1.0) STATUS='UNKNOWN') CALL CALL CALL CALL CALL CALL CALL GSWN( GSVP( GSWN( GSVP( GSELNT( 1) GCRSG( 3) CALL GSLN( 3) CALL GPL( 5,GV1X, GV1Y) CALL GCLSG CALL GCRSG( 5) GV3X(1)=0.0 GV3Y(1)=0.0 GV3X(2)=1.0 GV3Y(2)=0.0 GV3X(3)=1.0 GV3Y(3)=1.5 GV3X(4)=0.0 GV3Y(4)=1.5 GV3X(5)=0.0 GV3Y(5)=0.0 GVX=0.8 GVY=0.7 CALL GSLN( 1) CALL GPL( 5,GV3X, GV3Y) CALL GSMK( 4) CALL GPM(1,GVX, GVY) CALL GCLSG CALL GCRSG( 1) CALL GPL( 6,GV4X, GV4Y) CALL GCLSG CALL GCRSG( 7) CALL GEVTM(0.,0.,0.,0.,0. CALL GINSG( 1,GTRAN1) CALL GEVTM(0.,0.,2.0,0.0, CALL GINSG( 5+1 -1,GTRAN1) CALL GEVTM(0.,0.,0.6,2.0, CALL GINSG( 3+1 -1 ,GTRAN1) CALL GEVTM(0.,0.,3.7,2.0, CALL GINSG( 3+1 -1 ,GTRAN1) CALL GCLSG CALL GDSG( 1) CALL GRENSG( 7, 1) CALL GSELNT( 2) CALL GCRSG( 4) CALL GSLN( 3) CALL GPL( 5,GV2X, GV2Y) CALL GCLSG CALL GCRSG( 6) CALL GSLN( 1) CALL GPL( 5,GV3X, GV3Y) CALL GSMK( 4) CALL GPM(1,GVX, GVY) CALL GCLSG CALL GCRSG( 2) GV4X(4)=3.0 GV4Y(4)=3.7 GV4X(5)=2.0 GV4Y(5)=3.7 GV4X(6)=0.0 GV4Y(6)=3.2 1.,1.,0,GTRAN1) 0 ,1.0,1.0,0,GTRAN1) 0 ,1.0,1.0,0,GTRAN1) 0 ,1.0,1.0,0,GTRAN1) 105 CALL GPL( 7,GV4X, GV4Y) CALL GSCHSP( 1.5) CALL GSCHH( 0.10) CALL GTX(1.0,5.0,'WELCOME CALL GCLSG CALL GCRSG( 7) CALL GEVTM(0.,0.,0.,0.,0. CALL GINSG( 2,GTRAN1) CALL GEVTM(0.,0.,2.0,0.0, CALL GINSG( 5+2-1,GTRAN1) CALL GEVTM(0.,0.,0.8,2.0, CALL GINSG( 3+2-1,GTRAN1) CALL GEVTM(0.,0.,3.7,2.0, CALL GINSG( 3+2-1,GTRAN1) CALL GCLSG CALL GDSG( 2) CALL GRENSG( 7, 2) CALL GACWK( 2) CALL GSHLIT( 1+1-1,1) CALL GCSGWK( 2, 1 +1 -1) CALL GDAWK( 2) CALL GACWK( 2) CALL GSHLIT( 1+2-1,0) CALL GCSGWK( 2, 1+2-1) CALL GDAWK( 2) CALL GMSG( 3,'GOODBYE') C C GKS-SYSTEM CLOSE CALL GDAWK(1) CALL GCLWK(1) CALL GCLWK( 2) CALL GCLWK( 3) CALL GCLKS STOP END TO GKS') 1.,1.,0,GTRAN1) 0 ,1.0,1.0,0,GTRAN1) 0 ,1.0,1.0,0,GTRAN1) 0 ,1.0,1.0,0,GTRAN1)