jwp@uwmacc.UUCP (02/11/87)
I have asked questions about these things in the past, but I am still a little confused, so I thought I'd try again. I have a fair idea of what GKS is (standardized functionality) and what the binding is (standardized routine names and argument lists). Now, the GKS calls produce some generic information (is this the VDI?) that is interpreted by "drivers", right? 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? 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? Any GKS packages out there with postscript support? -- Jeff Percival ...!uwvax!uwmacc!sal70!jwp or ...!uwmacc!jwp
ghemawat@svax.UUCP (02/12/87)
--- From what I remember from last summer, there was no standard interface between the GKS kernel and device drivers. Different manufacturers might have their own interface to the drivers, and might publish it if they want to allow user written device drivers. Again, this is not current knowledge, but I doubt if the standard could have changed in such a manner at this late date. Good luck. -Sanjay Sanjay Ghemawat ghemawat@svax.cs.cornell.edu
twb@hoqax.UUCP (02/13/87)
In article <1049@uwmacc.UUCP>, jwp@uwmacc.UUCP (Jeffrey W Percival) writes: > ... > 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? > Jeff Percival ...!uwvax!uwmacc!sal70!jwp or ...!uwmacc!jwp The Computer Graphics Metafile (CGM) standard was due to be finalized 1/87. I don't know if it has been actually adopted. The GKS standard refers to the CGM in its appendix in addition to the GKSM (GKS Metafile). GKSM is not a standard, it includes both binary and clear text encodings, and is not necessarily portable between implementations. Tom. hoqaa!twb
thom@hpfcdq.UUCP (02/13/87)
> 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
miner@ulowell.UUCP (02/15/87)
In article <1049@uwmacc.UUCP> jwp@uwmacc.UUCP (Jeffrey W Percival) writes: > Now, the GKS calls produce some generic information >(is this the VDI?) that is interpreted by "drivers", right? Most implementations of GKS have a workstation layer below the GKS layer. This is sometimes referred to as a Virtual Device Interface (VDI- CGI). It is not necessarily interpreted by the device drivers. In our implementation, for example, the VDI level is implemented as a set of functions. GKS mapped and normalized data and attributes are passed from the GKS level to the VDI level where they are then mapped to a specific device using information in a virtual device table (VDT) and passed to the device driver. >A driver can go from VDI to, say, a TEK4014 or a Versatec. Yes, or a GKS could be implemented to communicate directly to a TEK4014, not very portable, but this is how many companies got GKS support in the old days. >It could also go from VDI to a metafile. Is this metacode >part of the standard? While meta files are required by GKS there have been a few evolving standards in the past which makes moving meta-files between different implementations of GKS difficult. GKSM was an originally proposed metafile format. Most people are now adopting CGM, Computer Graphics Metafile, which is becoming (or has recently become) an ANSI standard metafile format. >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.... If you have information on your GKS's metafile format then it should be a straight forward, but nontrivial, task to write a postscript conversion utility. >Any GKS packages out there with postscript support? The GKS group at ULowell has plans to eventually write a postscript driver for their GKS. In the meantime, since source is distributed with the system, it is quite possible that some GKS-UL users will write the driver before the Ulowell team gets to it. -- Rich Miner !ulowell!miner Cntr for Productivity Enhancement 617-452-5000x2693
news@rlvd.UUCP (03/05/87)
In article <1049@uwmacc.UUCP> jwp@uwmacc.UUCP (Jeffrey W Percival) asks some questions about GKS: > ... Now, the GKS calls produce some generic information >(is this the VDI?) that is interpreted by "drivers", right? The mechanism by which GKS controls workstations is entirely up to the implementer and there is *NO* standard VDI, though many implementers use the VDI from Graphic Software Systems. >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? The GKS standard defines one type of metafile in Annex E, but this doesn't have to be provided. You'll have to check your vendor's documentation and/or compare the output produced with the contents of the standard document (ISO 7942-1985. I don't know the ANSI document number). > ... 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? If they both use the same metafile format, yes. > ... Is this picture flawed in any big way? No. The problem is that it'll be a couple of years, with luck, before the standards for this area are published. Until then you'll just have to be very careful about getting packages that use the same driver interface and/or metafile format if you want to get drivers from a third party and/or transfer metafiles between packages. >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? If your vendor's VDI is the GSS version, you may be able to get a third party driver. Whether or not you can link this into your GKS depends entirely on what your vendor wanted to allow when they wrote it. For this reason - as long as you can find one that understands the metafile format your GKS uses - I'd go for a metafile to PostScript translator. You could use this as a filter without hacking your GKS about. >Any GKS packages out there with postscript support? The only GKS I know of with PostScript support (in the form of an Apple Laserwriter driver) is Visual Engineering GKS. Their address is: Visual Engineering 2680 North First St. Suite 200 San Jose, CA 95134 When last I heard it was a level 2b GKS, written to the ANSI standard (ie the Aspect Source Flags default to INDIVUDUAL, rather than BUNDLED as in the ISO standard). I haven't used it myself and I don't know if they sell drivers separately. You can but try. Needless to say I am in no way connected with any company or group mentioned in this article, nor does anything above reflect the opinions or policy of my employers. Good Luck! ------------------------------------------------------------------------------- Pete Randall. | Informatics Division. | Rutherford Appleton Laboratory, UK JANET: pete@uk.ac.rl.pyr-a | Chilton, DIDCOT, Oxon OX11 0QX. | UUCP: ...!mcvax!ukc!rlvd!pyr-a!pete | Tel: (0235) 21900 x 5707
news@rlvd.UUCP (03/05/87)
In my previous response to <1049@uwmacc.UUCP>, I said that ANSI GKS differed from ISO GKS in that it set the default Aspect Source Flags to INDIVIDUAL rather than BUNDLED. This was wrong. The default Aspect Sourec Flags are implementation dependant. Sorry for any confusion caused - I won't submit articles on Monday mornings in future! ------------------------------------------------------------------------------- Pete Randall. | Informatics Division. | Rutherford Appleton Laboratory, UK JANET: pete@uk.ac.rl.pyr-a | Chilton, DIDCOT, Oxon OX11 0QX. | UUCP: ...!mcvax!ukc!rlvd!pyr-a!pete | Tel: (0235) 21900 x 5707