DECGKS: Coexistence with GKSGRAL and Implementation

One of the advantages of using an ISO standard graphics package is that users are not limited to the products of a single supplier. Thus, although the principal GKS implementation supported at CERN is that of GTS-GRAL, users of Digital Equipment Corporation (DEC) machines may wish to use the DEC implementation of GKS. This might be because of the availability of drivers, or because the performance of DEC software on the company's own machines is likely to be better than that of third party software suppliers who are constrained to ensure that their libraries operate in many different environments.

Whilst there are no major problems in moving between DECGKS and GKSGRAL there are several implementation dependencies, and these are documented below. A large number of routines have been added to the set of tools in GKSPACK (see section on Page ). Some of these have been written in order to aid the portability of applications between different GKS implementations by supplying information about the Workstation Types and Connection Identifiers of a particular implementation. Other routines have been provided to emulate extensions of GKS available in the GKSGRAL implementation. Whilst users of GKSGRAL will have these routines available in the GKSGRAL library, users of DECGKS will need to link to an additional library containing a version of GKSPACK tailored for the DECGKS implementation. This library is called GKSPACK_DEC.OLB, and on the CERN VAX cluster may be found in:

GKS_ROOT:[LIB]GKSPACK_DEC.OLB

• Workstation Types and Connection Ids

  Implementations are free to choose whichever Workstation Types and Connection Identifiers they wish. Thus, those in use by GKSGRAL and DECGKS do not match. The routines in the library GKSPACK go some way to alleviating this problem (see section on Page ).

• Fonts and Attributes

  Neither GKS, nor any other Graphics Standard, defines the shapes of the characters corresponding to a particular font number. In addition, a particular implementation may provide access to hardware fonts on some devices. This also applies to hatch styles and patterns, etc. The fonts and hatch styles available from GKSGRAL are defined in on Page , and a brief comparison of the two implementations follows:

     GTSGRAL                    |         DECGKS
  

  Hardware Fonts:

  See wk descr. tables          |  DECWINDOWS : -101 to -113
                                |  UIS        : -200 to -202
  

  .pa

  Software Fonts

  -1 to -11: normal,proport.    |  font 1 = font -1 = DEC GKS
                                |  multinational font
  -13      : greek              |
  -51      : solid filled font  |
  same font numbers - 100:      |  -2 to -23: Hershey fonts
    idem but italics            |
  same font numbers - 200:      |
    idem but monospaced         |
  same font numbers - 300:      |
    idem but italics monospaced |
  

  Line types

                                |  -1 to -8  DEC specific
  

  Marker Types

  -101 to -114 GKSGRAL specific |  -1 to -13 DEC specific
  

  Fill Area Hatch Styles

   -101 to -124 (CERN specific) |  -1 to -33 (UIS specific)
                                |  -1 to  -9 (DECwindows specific)
  

  Fill Area Patterns

        None                    |   1 to 196 (UIS specific)
                                |   1 to  28 (DECwindows specific)
                                | -29 to -58 (DECwindows specific)
  

• Data Records

  Both the contents and internal format of data records used by GKSGRAL and DECGKS are different. The format should not affect the majority of users, who would not require to access data record explicitly. However, users will be affected by the differences in data record contents if they make use of facilities to initialize input devices or use GDPs.

  To help solve this problem, higher-level routines have been provided by GTS-GRAL which hide details of the data record contents. These include GUARC, GUBEZ1, GUCIR1, GUCIR2, GUCUR1, GUELL1, GUELL2, and GUMEN2. The library GKSPACK_DEC.OLB, described in section on Page , contains emulations of these routines which work with DECGKS.

• Metafiles

  Whilst the content of the GTS-GRAL and DECGKS metafiles are logically the same, the file formats are not. In order that the CERN metafile utility programs GRVIEW and GRPLOT may be used with metafiles produced with DECGKS, an option will be introduced into GRCONV to convert them to the same format as those written by GTS-GRAL (but not vice versa). Until this feature is installed, anyone wishing to convert a DECGKS metafile should contact the UCO. .pa

• Input

  Whilst stroke input requires a trigger for each locator position in the GTS-GRAL GKS implementation, that of DEC does not, but simply samples the locator position at fixed time or distance intervals. Thus, GTS-GRAL's stroke input is more or less equivalent to calling Request Locator in a loop. In order to provide functionality when using DECGKS equivalent to that in GKSGRAL, a CERN-written version of GRQSK may be found in the library GKSPACK_DEC.OLB.

  The DECGKS implementation uses separate windows for messages and also for string, choice, and valuator input. The window size depends on the echo area specified in GINST, GINCH, and GINVL.