-------------------------------------------------------------------- ISO/IEC JTC1 SC22 WG16 N185 Proposal for Graphics Primitives in ISLISP 2000 -------------------------------------------------------------------- Source: Whitman Wright (Canada HoD) Action: Discussion at WG16 15th meeting, under agenda item 11 -------------------------------------------------------------------- PROPOSAL FOR GRAPHICS PRIMITIVES IN ISLISP 2000 by Whitman Wright November 1996 Canada The body of this document was prepared for Fortran 2000. However, the situation for ISLISP is somewhat similar. Because of time pressures, I was not able to rewrite this document for ISLISP in time for the BATH WG16 meeting in November, 1996, for which I offer my apologies. However, this document should be adequate as a basis for considering primitives in graphics as a candidate for inclusion in ISLISP 2000. ------------------------------------------------------------------- PART 1 THE CANADIAN FORTRAN 2000 PRIMITIVE GRAPHICS PROPOSAL The Canadian proposal is that Fortran 2000 be given a set of primitive capabilities that would permit graphic objects to be placed on a display surface. Fortran now has very adequate facilities for developing the software required for performing the higher graphic operations such as clipping, scaling,the execution of other transformations, and doing three-dimensional modelling. However, it does not have the facilities for performing the elementary graphic functions such as drawing or picking a point on a display screen. The result is that a program written in Fortran must use non-standard features if it is to perform any graphic operations. Thus, if the program is to be later transferred to another different platform, the graphic part has to be re-written specifically for the new platform. While this limitation of standard Fortran may not present difficulties for Fortran users having the appropriate resources and technical knowledge, it does present difficulties, often insurmountable, for many Fortran users with fewer resources. In the past, Fortran has been especially suited for use by scientists and engineers who are experts in their own disciplines first, and programmers only secondly. These people badly need access to convenient computer graphics, not necessarily the powerful computer graphics required by CAD systems or commercial displays, but enough graphics to permit them to develop programs that will produce graphs, figures and diagrams. Even the computational efficiency of certain commercial graphics systems is not required because of the speed of modern CPUs. For example, many programmers and users could live with software clipping in Fortran rather than clipping by hardware or assembler, if the only alternative were non-portable programs. What is required is access to the very basic graphic primitives in a platform-independent manner. This would permit the computational power of Fortran to be used for the development of specialized in-house programs by scientists and engineers having modest computer expertise. Such programs could be easily moved from one platform to another. In this proposal, we have avoided, at this time, the exact setting forth of the primitive graphic features which we would like to see contained in Fortran 2000. These features should be the minimum required to permit a variety of types of graphic displays. Any feature that could be implemented with reasonably efficient software written in present-day Fortran should probably be omitted at this time. For example, no new Fortran features are required to do graphic scaling and panning. Present-day Fortran is very adequate for that purpose. Some of the features that should be provided are as follows: (1) Turning on and off of the graphics mode. (2) Some control over the number of pixels to be used horizontally and vertically to represent the display surface, of course subject to the limitations of the graphics hardware in use. (3) Some control over colour ranges, again subject to hardware limitations. (4) An ability to draw a point (a pixel) on a selected location on the display surface, using a colour selected from the colour palate in use. Once this capability is available, almost any graphic display can be done using present-day Fortran, although perhaps not as quickly as with specialized graphic systems. (5) An ability to pick a selected point on a display surface using a pointing device such as a mouse. This would permit drawing and editing directly on the screen. Some features that would be less essential but nevertheless desirable would be: (1) The drawing of straight lines between any two points on the display surface. This would permit the Fortran programmer to produce software that would draw a variety of curved and/or broken lines with more efficiency than if only pixels were available. (2) A minimum set of text fonts with size, colour, location and orientation under the control of the Fortran programmer. This feature would promote speed and simplify programming. (3) Boundary clipping. This may save the Fortran programmer some trouble. The objective would not be to provide in Fortran the resources necessary to develop efficient CAD or commercial display systems in a platform-independent manner. The programmers of such systems would be expected to have the technical and other resources to develop such systems for each individual platform intended to be used. The provision of the facilities for developing such systems in platform-independent Fortran could place an unreasonable burden on Fortran compiler writers at this time. It may be suggested that X-Windows, the various versions of Microsoft Windows such as 3.X, 95 or NT, or the hopefully forthcoming Posix graphic features, will have the effect of making our proposal unnecessary. In practice, at this time and in the foreseeable future, none of these systems has or is likely to have anything at all close to universal acceptance. Another alternative that may be proposed is a more widespread use of the GKS or PHIGS standards. The GKS standard is now approximately ten years old and substantial differences of opinion between different users seem to be impeding the updating of the Standard. The software necessary to implement the GKS Standard does not appear to be readily available for some important platforms. When it is available, it may be expensive for users with limited resources and it may provide much functionality that is not needed, redundant or even in the way for many users. By contrast, the Fortran code required to exploit the proposed primitive Fortran graphic functions can easily developed, published, and made available to Fortran programmers with limited resources. The required algorithms are generally readily available to programmers having some initiative. Something similar has already been done for certain platform-dependent versions of the programming language Basic. However, the benefits of such work in Basic have been limited because of the platform-dependence problem. The example of Basic is an interesting one. In spite of their substantial limitations, platform-dependent versions of Basic continue to be used on a substantial scale in scientific and engineering offices because these versions of Basic contain graphic primitives which can be used to good effect by unsophisticated programmers. I would be pleased to have the opportunity to discuss this proposal with any of the delegates to the present Dresden WG5 meeting on Fortran. Whitman Wright, Ph.D., P.Eng. Canadian Delegate for Fortran Dresden, July, 1996 ------------------------------------------------------------------- PART 2 GRAPHICS PROPOSAL FOR FORTRAN 2000 PREFACE At the ISO WG5 Fortran meeting held in Dresden in the summer of 1996, a primitive graphic capability for Fortran 2000 became a serious issue with the establishment of ISO WG5 Committee 3. Primitive graphics in Fortran was designated as one of the topics to be dealt with by that committee and I became a member of that committee with the expectation that I, at least, would pursue the graphics issue. This present document is the first draft of a report concerning the possibility of computer graphics in Fortran 2000, which I am directing to the repository for Committee No. 3 under the charge of Dr. Christian Weber of Munich, Germany. After returning home to Ottawa, Canada, I have devoted what time I could spare to this topic. First, I studied the topic at the Assembler level on the MS DOS system, in order to obtain a better appreciation of the technical problems to be encountered by compiler writers. Then the Canadian Standards Association Programming Languages Committee designated me as their liaison person to the Canadian SC24 Graphics Committee. So far, I have been able to have a very limited amount of Email contact with Professor Tom Kurtz of Dartmouth College and Basic fame. The ISO and ANSI Basic standards have certainly incorporated graphics, substantially more so than I am advocating for Fortran. I hope to have further communication with Professor Kurtz and find out more about how well industry has received the Basic standards. Living in Ottawa, I am fortunate to have easy access to the library of the Standards Council of Canada, which contains all the standards documents that I have required access to so far, although photocopying and borrowing are not permitted. In addition to the GKS, PHIGS, Graphic Metafile and Basic standards, I have discovered two relatively new groups of standards, as follows: (1) ISO/IEC 9636-1991, Parts 1 through 6, Information technology - Computer graphics - Interfacing techniques for dialogues with graphical devices (CGI) - Functional specifications. (2) ISO/IEC 9637-1994, Parts 1 and 2, Information technology - Computer Graphics - Interfacing techniques for dialogues with graphical devices (CGI) - Data stream binding. Reference to these two groups of standards in the Fortran 2000 Specification and the use of these standards by compiler writers should make the incorporation of primitive graphics in Fortran 2000 much simpler. There is a great deal of relevant information in the standards and text books. I have only been able to digest a relatively small part of it so far, and feel very much in need of constructive comment from those more expert in this area than I am. I hope that such comment will be forthcoming and that it will be constructive. The task will be to select from the capabilities described in the standards what is essential for a graphics capability in Fortran 2000 and not too much more. As a result of my work on the topic since Dresden in the summer of this year, I am if anything more convinced than ever of the need for a primitive graphics capability in Fortran. With today's combination of high technical complexity and rapid change, many things fall through the cracks or between the chairs. One of these things has been computer graphics for limited market professional use software on low cost systems. An example has been the practical unavailability of GKS on MS DOS and on the various levels of Microsoft Windows. This is an issue which I have raised before but will not expand upon further here. Whitman Wright Member of WG5 Committee No. 3 Planning for Fortran 2000 ------------------------------------------------------------------- CONTENTS 1. General 2. The Programming Languages 'ANSI Basic and ISO Full Basic as Demonstrations that It Can Be Done 3. The Place of Graphic Primitives in the Fortran Standard 4. The Use of the GKS Fortran Binding Standard (ISO 8651-1) as the Starting Point for Fortran 2000 Graphics 5. Graphic Subroutines Proposed for Inclusion in Fortran 2000 6. Binding of the Fortran Code to the Graphic Hardware 7. References 1. GENERAL The intent of this proposal is to provide the minimum graphics that will be useful for producing portable software with a graphics component. No attempt will be made to duplicate any feature pertaining to graphics that can be produced with reasonable efficiency using existing or anticipated Fortran. For example, there will be no need to provide for the following features: The third dimension. Scaling. Panning. Possibly clipping. 2. THE PROGRAMMING LANGUAGES 'ANSI BASIC' AND 'FULL BASIC' AS DEMONSTRATIONS THAT IT CAN BE DONE It has been argued by compiler writers and others that a graphic capability in standard Fortran would place an unreasonable burden on writers of compilers for Fortran. The production of the recent standards for ANSI Basic and Full Basic is a demonstration that a capability for graphics primitives in Fortran 2000 is an achievable objective. 3. THE PLACE OF GRAPHICS PRIMITIVES IN THE FORTRAN STANDARD We recommend that, for at least the Fortran 2000 standard, the graphics features be optional. For compilers for which it is claimed the graphics features are implemented, it would be required that a list of the levels of graphics supported be published as part of the documentation. For example, a particular compiler might support VGA graphics for Windows 95, but not EGA graphics for DOS. Whether a particular Fortran compiler will contain an ISO graphic capability will become an economic decision for the compiler writer. 4. THE USE OF THE GKS FORTRAN BINDING STANDARD (ISO 8651-1) AS THE STARTING POINT FOR FORTRAN 2000 GRAPHICS The use of the GKS Fortran Binding Standard ISO 8651-1:1988 as a starting point for Fortran 2000 graphics is recommended for the following reasons: (1) The great deal of thought already embodied in that standard could be utilized. (2) The transition between the use of graphics in GKS and graphics in Fortran can be made easier for programmers already familiar with one of those two alternatives. The substantial tasks in proposing a graphics capability are then: (1) Selecting an appropriate subset of the GKS Fortran binding subroutines for inclusion in Fortran 2000. (2) Examining the subroutines selected in order to see whether they should be modified in some way when they are included in the Fortran 2000 standard. The GKS Fortran Binding subroutines are intended for Fortran 77. It is not anticipated that there will be any great difficulty in adapting these subroutines to Fortran 2000. 5. GRAPHIC SUBROUTINES PROPOSED FOR INCLUSION IN FORTRAN 2000 (Taken from GKS Fortran Binding) ISO 8651-1 - 9.2 Control Functions SUBROUTINE GOPKS (ERRFIL,BUFA) Enter integer ERRFIL: Error message file. Enter integer BUFA: Amount of memory units (implementation dependent): if -1, use implementation dependent default. Question: How does one match up a number with a specific graphics board, say VGA? GKS equivalent: OPEN GKS SUBROUTINE GCLKS GKS equivalent: CLOSE GKS SUBROUTINE GOPWK (WKID,CONID,WTYPE) Enter integer WKID: Workstation identifier. Comment: Could be display surface identifier. Question: How does one associate a particular integer with a particular display surface. Enter integer CONID: Connection identifier. Enter integer WTYPE: Workstation type. GKS equivalent: OPEN WORKSTATION SUBROUTINE GCLWK (WKID) Enter integer WKID: Workstation identifier. GKS equivalent: CLOSE WORKSTATION SUBROUTINE GACWK (WKID) Enter integer: WKID: Workstation identifier. GKS equivalent: ACTIVATE WORKSTATION SUBROUTINE GDAWK (WKID) Enter integer WKID: Workstation identifier. GKS equivalent: DEACTIVATE WORKSTATION SUBROUTINE GCLRWK (WKID,COFL) Enter integer WKID: Workstation identifier. Enter integer COFL: Control flag (GCONDI,GALWAY) GKS equivalent: CLEAR WORKSTATION SUBROUTINE GRSGWK (WKID) Enter integer WKID: Workstation identifier. GKS equivalent: REDRAW ALL SEGMENTS ON WORKSTATION SUBROUTINE GUWK (WKID,REGFL) Enter integer WKID: Workstation identifier. Enter integer REGFL: Update regeneration flag (GPOSTP,GPERFO) GKS equivalent: UPDATE WORKSTATION SUBROUTINE GMSG (WKID,MESS) Integer WKID: Workstation identifier. Character* (*) MES = message. GKS equivalent: MESSAGE ISO 8651-1 - 9.3 Output Functions SUBROUTINE GPL (N,PXA,PYA) Enter integer N: Number of points to be drawn. Enter real PXA(N), PYA(N): World coordinates of points to be drawn. Comment 1: See ISO 8651-1, page 102. Comment 2: Dashed lines and other special lines are built up using standard Fortran. Curved lines are built up using short polyline segments and are constructed using standard Fortran. Line widths are controlled by standard Fortran subroutine CALL LINEWIDTH. GKS equivalent: POLYLINW SUBROUTINE GMP (N,PXA,PYA) Enter integer N: Number of points to be drawn. Enter real PXA(N),PYA(N): World coordinates of points on display. GKS equivalent: POLYMARKER SUBROUTINE GTX (PX,PY,CHARS) Enter real PX,PY: Text position, in world coordinates. Enter character* (*) CHARS: String of characters. Comment: See Standard, page 114. GKS equivalent: TEXT SUBROUTINE GFA (N,PXA,PYA) Enter integer N: Number of points to be drawn. Real PXA(N),PYA(N): World coordinates of points to be drawn. Comment: It would be desirable to coordinate the "fill" points with the "natural grid" of the display surface. GKS equivalent: FILL AREA The following are not taken from ISO 8651-1: SUBROUTINE LWDTH (LWIDTH) Enter real LWIDTH: Line width for the next objects, in world coordinates. SUBROUTINE COLOR (COLR) Enter integer COLR: Color code for the next objects. SUBROUTINE TXTSIZ (TSIZ) Enter real TSIZ: Text height for the next lines of text, in world coordinates. SUBROUTINE TXANG (TANGL) Enter real TANGL: Text angle from the horizontal for the next lines of text, counterclockwise positive (radians). SUBROUTINE MSPIK (XPIK,YPIK) Return real XPIK,YPIK: World X and Y coordinates picked on the display surface by a picking device. SUBROUTINE DMAP (LLX,LLY,URX,URY) Enter real LLX,LLY,URX,URY: Lower left and upper right X and Y, expressed in world coordinates. Note: This subroutine effectively sets the scale of the graphic display. The scale is set so that both the lower left and upper right control points LLX, LLY, URX and URY are on boundaries of the display surface. If the aspect ratio implied by these two points does not correspond to the aspect ratio of the display surface, the aspect ratio implied by the control points will be maintained, with the graphic display centered on the display surface. 6. BINDING OF THE FORTRAN CODE TO THE GRAPHIC HARDWARE The binding of the Fortran code to the graphic hardware shall be through two groups of ISO standards, as follows: (1) ISO/IEC 9636-1991, Information technology - Computer graphics - Interfacing techniques for dialogues with graphical devices (CGI) - Functional Specifications: Part 1 Overview, profiles and conformance Part 2 Control Part 3 Output Part 4 Segments Part 5 Input and echoing Part 6 Raster (2) ISO/IEC 9637-1994, Information technology - Computer graphics - Interfacing techniques for dialogues with graphical devices (CGI) - Data stream binding: Part 1 Character encoding Part 2 Binary encoding 7. REFERENCES ISO/IEC 10279 Full Basic ISO 7942-1 GKS Part 1 ISO 8651-1 GKS - Fortran Binding ISO/IEC 8806-4 GKS - 3D ISO/IEC-9592-1 PHIGS Part 1 ISO/IEC-9592-2 PHIGS Part 2 ISO/IEC 8632-1992 Computer Graphics Metafile ISO/IEC 9636-1991, parts 1 through 6, Information technology - Computer graphics - Interfacing techniques for dialogues with graphical devices (CGI) - Functional specifications ISO/IEC 9637-1994, parts i and 2, Information technology - Computer graphics - Interfacing techniques for dialogues with computer graphical devices (CGI) - Data stream binding ISO 2382-13: 1984 Data Processing - Vocabulary Part 13: Computer Graphics ANSI X3.113-1987 ANSI Full Basic. Graphics is dealt with in Section 13. The facilities provided are a subset of ISO GKS 7942-1985 (which has been superseded). ------------------------------------------------------------------- PART 3 GRAPHICS PROPOSAL FOR FORTRAN 2000 November 4, 1996 INTRODUCTION In October, 1996, I submitted an expanded discussion of my Fortran 2000 graphics proposal to Dr. Christian Weber. Mr. Weber supplied some brief comment , which indicated to me the need for me to go into further detail with respect to the specifics of my proposal. Since it now seems that what I called Draft 1 will be a relatively stable document, I would now like to call it "GRAPHICS PROPOSAL FOR FORTRAN 2000 - PART 2". My original proposal which I submitted in Dresden last summer should be called Part 1, and this present document should be called Part 3. REFERENCES IN PART 2 TO EXISTING ISO STANDARDS INVOLVING GRAPHICS In Part No. 2, I refer to existing standards (particularly BASIC, GKS and PHIGS) not in an attempt to duplicate them in Fortran, but rather to learn from them what can be learned. These standards go far beyond what many software developers would need in Fortran and far beyond what I would advocate for Fortran graphics. I happen to be in the perhaps fortunate position where I have easy access to these standards and can pick out what seems to be useful for our purpose. However, I believe that what we need to decide is what would be required for Fortran graphics in its own right, and whether the potential benefits to Fortran users could justify adding a specific graphics feature to Fortran. It should not be necessary for the critics of the Fortran primitive graphics proposal to have access to the other standards that I have referred to in Part 2. The standards ISO/IEC 9636 and 9637, referred to in Part 2 need not even be mentioned in the Fortran 2000 specification, although they probably should be discussed in any commentary to that specification. Mr. Tom Kurtz of Dartmouth College in New Hampshire, U.S.A. (author of BASIC), believes that these standards have not yet had much use by developers of graphics hardware, since the availability of these standards has been very recent. In the future their role should be somewhat analogous to an output standard for BIOS in MS-DOS, permitting a kind of standard interface between the hardware and work of the Fortran graphics compiler writer. These specifications should be helpful, but perhaps only in the longer run. OVERALL OBJECTIVE OF THIS FORTRAN GRAPHICS PROPOSAL The overall objective has been stated before, but perhaps it needs to be stated again and again so that we stay on track. The overall objective is to provide a useful but not necessarily highly efficient or specialized portable graphics capability for Fortran users who wish to do some graphics, but do not have convenient access to other modes of computer graphics expression. Capabilities that can be developed with reasonable efficiency in existing Fortran are not to be duplicated. Having affirmed these general objectives, we recognize that there are some grey areas where it is not obvious and perhaps not important whether additional capabilities should be added beyond what Fortran already has to offer. Some such capabilities are clipping, panning and text generation. DISCUSSION OF FUNCTIONS TENTATIVELY PROPOSED IN PART 2 The reader should refer to Section 5 of Part 2. GOPKS, GCLKS: I have not yet thought these items out in detail. Some function may be necessary to change from an alphanumeric mode to a graphic mode and back again, and/or perform the rough equivalent to OPEN file and CLOSE file. GOPWK: I believe that one has to be able to identify the display surface, e.g. screen or hard copy. GCLWK, GACWK, GDAWK, GCLRWK: May not be necessary as independent functions. However the operations involved need to receive very detailed study to ensure that all the common graphic operations can be carried out without an excessive loss of efficiency. GRSGWK, GVWK: Convenient but probably not necessary. World Coordinates and Display Surface Coordinates: One could get by using only display surface coordinates. However the advantage of having both world coordinates and display surface coordinates are so great that both should be included. GLP: There is a mistake in Part 2. This function refers to lines, not points. Unless one works only with pixels, which is very inefficient at least on some platforms, it is necessary to be able to draw solid straight lines. Dashed and other special lines can be built up from solid straight lines, using present-day Fortran. (When I refer to Fortran in this manner later in this document, I mean present-day Fortran without any graphic capability) Wide (thick) lines could be built up from multiple pixels or close parallel lines. However a function controlling line width is probably desirable. Curved lines can be built up in present-day Fortran, using short straight-line segments. Multiple lines or curved lines composed of short straight segments can be handled using Fortran DO-loops. World coordinates rather than scree coordinates should be used for line-work. GMP: One can have different kinds of "points", dots, crosses, X's and O's etc. However, these could be built up using Fortran using individuals or very short lines. Special kinds of points should probably not be provided for but individual pixels should be available for use. LWIDTH: Should be included. The alternative is to build up line width from individual pixels or close parallel lines, both of which may be inefficient. COLOR: This topic needs to be addressed in some manner. Otherwise the programmer is limited to using monochrome. FILL: I am not satisfied with what has been proposed in Part 2 for fill. In principle, this could be dealt with in Fortran, pixel by pixel, but this would not be efficient. There is also the problem of the degree of coarseness of the display surface. The alternative is to fill up to the prescribed boundaries of a graphical object, which has its own complications, especially when we are attempting to use only primitive functions. This topic will have to be given more thought. Text Functions: Strictly speaking, these could be avoided in the standard and generated stroke by stroke using Fortran. They would be a substantial convenience to have in the standard. However, once text is introduced, unless it is kept very primitive, the number of functions that seems to be needed quickly becomes very large. I would be tempted to omit text, but I am not sure that would be the correct decision. DMAP: There is a great deal of merit in keeping screen coordinates and world coordinates separate. There is also much merit in maintaining a true aspect ratio rather than having the requirement that the whole display surface be included regardless of the distortion. It is also desirable that the whole mapped area be visible with the display scale adjusted to suit. CLIP and INTERIOR_CLIP: These functions can be performed using present-day Fortran but in Fortran they can be time-consuming to execute. They could be included or left out. PICK: It would be very desirable to pick an X-Y position on the display surface, preferably in world coordinates. CLOSING COMMENTS The comments contained in this document are intended to promote progress in the consideration of primitive graphics capabilities for Fortran 2000. However they do not represent any fixed or final position. Constructive comments are needed, and if these are forthcoming, it should be possible to prepare a very good proposal for primitive graphics in Fortran 2000 -------------------------------------------------------------------