Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-unix!hplabs!hpcea!hpfcdc!hpfcdq!thom
From: thom@hpfcdq.UUCP
Newsgroups: comp.graphics
Subject: Re: GKS, Postscript questions (summary needed)
Message-ID: <330001@hpfcdq.HP.COM>
Date: Fri, 13-Feb-87 13:14:16 EST
Article-I.D.: hpfcdq.330001
Posted: Fri Feb 13 13:14:16 1987
Date-Received: Sun, 15-Feb-87 22:40:22 EST
References: <1049@uwmacc.UUCP>
Organization: Hewlett Packard, TWO
Lines: 56

> I have a fair idea of what GKS is (standardized functionality)
> and what the binding is (standardized routine names and argument
> lists).

So far, so good. 

>          Now, the GKS calls produce some generic information
> (is this the VDI?) that is interpreted by "drivers", right?

Well, this part really isn't specified by the standard.  At least 
from the standpoint of how a GKS must be implemented.  There are
standards that address an application program interface at the level
of GKS (GKS is one of those) and there is a separate standard that addresses
an interface at a lower level in the graphics system, generally referred to
as the VDI.  The standards do not mandate how these interfaces must be 
provided, more specifically they do not mandate that a GKS really be 
implemented on top of a standard CGI (the name for the standard graphics
VDI), but they don't preclude it either (at least that's a goal).  So from
the standpoint of your question, all you can be sure is that you make
GKS call's and something happens on the devices on the workstation.  What
happens in between is not specified by the standard, but may be specified
by the implementation.  

> A driver can go from VDI to, say, a TEK4014 or a Versatec.
> It could also go from VDI to a metafile.  Is this metacode
> part of the standard?  Can I produce a metacode file using
> vendor A's software, and plot it on a versatec using vendor
> B's metacode-to-versatec interpreter software?  Is this picture
> flawed in any big way?

I'm not quite sure how to address your questions here except to try to
further clarify the CGI and CGM, which are standards at the the level
of a graphics VDI.  However, since your question is really couched in 
terms of GKS, that might really not be addressing your question, so instead
I will point you toward a more detailed reference on graphics standards
for further clarification:  "IEEE Computer Graphics & Applications",
August 1986, Volume 6, Number 8.

> See, we have a GKS package from a vendor, without a postscript driver.
> We also have a postscript printer.  Do we need a whole new GKS
> package with a postscript driver included, or is it sufficient
> to advertise for a "metacode-to-postscript" driver?

Well, both options are certainly possible.  I guess it would be best for
you to ask the vendor of your GKS.  Does your GKS implementation provide
support for GKSM or CGM metafile output.  These are standard graphics 
information interchange vehicles (well the GKSM is defined, but not required
by the GKS, but ...) and there might very well be a product out there that
interprets CGM or GKSM metafiles and outputs them to a printer which
talks postscript.  Sure sounds like a viable product to me, but I don't 
know of any. 

I hope I have shed some light on the situation for you.

-- Tom Morrissey.
hplabs!hpfcla!thom