[net.graphics] Query: ACM Core graphics for unix & a graphics terminal?

planting@uwvax.UUCP (W. Harry Plantinga) (11/06/84)

Does anyone know of packages which will run on (preferrably 4.2) Unix,
which are designed to use some particular graphics terminal, and which
implement the ACM Core graphics specification?  I know that the Sun
has SunCore, but I would like a package to run on the Vax with some
graphics terminal.

If possible, I would appreciate information about price, availability,
contact address, completeness, speed, etc.

			-Harry Plantinga
			 arpa:  planting@wisc-rsch.arpa
			 use:   {inhp4, seismo}!uwvax!planting

herbie@watdcsu.UUCP (Herb Chong, Computing Services) (11/10/84)

I may be wrong, but doesn't ISSCO support the CORE graphics specifications?
We have it here running on IBM VM/CMS, 4.2bsd, VMS, and Honeywell
GCOS8.  It suppports some 200 different devices and we develop and
provide some device drivers that ISSCO adopts.  Their address is:

ISSCO Graphics
4186 Sorrento Valley Blvd.
San Diego, CA  92121-1486
(714)452-0170
Telex: 697810

If you're doing any animation or solid modelling, this probably isn't
what you want, but if display grapphics are all that you are after,
we have found this package to be pretty good.

Herb Chong...

I'm user-friendly -- I don't byte, I nybble....

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA:  herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
NETNORTH, BITNET: herbie@watdcs, herbie@watdcsu

dhs@iddic.UUCP (David H. Straayer) (11/13/84)

- 
 Question on the net recently: Doesn't ISSCO support ACM CORE Standard?  
 Answer: No. Core was a proposal of ACM/SIGGRAPH.  ANSC X3H3 was
established under ANSI procedures to adopt Core as an American
National Standard in 1979.  That goal has been abandoned in favor
of adopting GKS, the Graphical Kernel System instead.  (If you
translate "Core Graphics System" into German, and then translate
the result back into English, you get Graphical Kernel System.)
GKS is very similar in intent to the Core proposal.  Chief
differences: GKS is 2D (3D GKS as a standard planned in about 12
months), and loss of the "current position" inherent in Core (No
Big Deal).  GKS is being adopted as American standard, is already
adopted in Britain and Germany, and in various stages as an ISO
International Standard and in Canada, Netherlands, France,
Austria,...  For a while, SIGGRAPH and ACM folks toyed around
with the idea of trying to establish ACM as an official standards
making body (it isn't) and promoting CORE as an "ACM Standard".
While the idea of ACM making standards is still moving forward
(slowly), the SIGGRAPH Board of Directors voted unanimously in
October '84 to abandon any attempt to promote Core as a
"standard".  In fact, ISSCO has announced that they will be
selling a GKS (not Core) package.  IBM, Tektronix, DEC, Megatek,
Ramtek, ISSCO, Precision Visuals, Chromatics, Cray, Nova, Uniras,
Visual Engineering, Data General, Graphic Software Systems and
others have all announced GKS products, and some have been
shipping for some time.  

One other important difference between Core and GKS is that Core
had only a functional specification (semantics but no syntax).
Thus, it is difficult to port application code from one
implementation of Core to another.  GKS has "bindings" in
languages.  Fortran is complete, and C, Pascal, and ADA are being
worked on right now.  I have ported applications from one GKS to
another, and its pretty trivial.  

David H. Straayer
Tektronix, Inc.
POB 1000 MS 63-296
Wilsonville, OR 97070
(503) 685-3544
(decvax,ucbvax,...)!tektronix!iddic!dhs

works@kiet.UUCP (Workstation) (01/08/85)

This is what I read on the Usenet a while ago.

Choong Nyun, kim
...!hplabs!kaist!kiet!works

***************************************************************************

Here is some more info about implementations of the Core and GKS under
UNIX.  (It was culled from the ARAPnet's INFO-GRAPHICS archives.)

Jeff Elman
Phonetics Lab
Dept. of Linguistics, C-008
Univ. of Calif., San Diego
UUCP:      ...ucbvax!sdcsvax!sdamos!elman
ARPAnet:   elman@nprdc

------------------------------------------------------------------------------

From: Steve Rubin <Strubin at SRI-KL>
Subject: Re: Graphics Software for VAX/UNIX

I have a C-language version of the SIGGRAPH Core at a basic level (2-D only,
no segmentation, some input primitives).  The program runs under 4.1bsd UNIX
and supports about nine different devices with more to come:  AED-512 frame
buffer, Ikonas frame buffer, Raster Technologies model one frame buffer,
ID100-V graphics terminal, Versatec V-80 plotter, Ramtek color printer,
Symbolics laser printer, CIF (for putting graphics on your VLSI chips), and
normal video terminals with TERMCAP cursor control.  Release status is not
known yet, but further information will be available soon.  Documentation is
available now.

		-Steve Rubin
		 Fairchild

------------------------------------------------------------------------------
------------------------------------------------------------------------------

From: Randy.Pausch at CMU-CS-G at CMU-CS-A
Subject: gen. purpose graphics software

Contact Joe Pato at Brown University -- they distribute (or did, anyway) a 2D
subset of the CORE standard, I believe available in both C and Pascal.

------------------------------------------------------------------------------
------------------------------------------------------------------------------

From: Michael Wayne Young <Michael.Young at CMU-CS-A>
Subject: Re: Graphics Software for VAX

I have such a package in the works for 4.1BSD; it's a SIGGRAPH "Core" system
written for any version 7 or better system (which of course includes System
IIII or 4.1BSD running on Vaxen).  It currently supports level 1 input and
level 1 output; that is, full 3D viewing, no segmentation, no input.  It
supports the definition of various attributes (such as color, which is what
you're interested in); it's up to the device driver to decide how much to
actually implement though, and the devices I've had are primarily monochrome
(4010 series, hp2648, Tek 4025), but some support color (an AED 512, a Dec
Gigi terminal, and an hp7221 plotter [4 pens]).

Maybe I should tell you a bit about the status of my project:

	Currently, all of level 1 i/o is complete; it is currently
	in use in part of a larger graphics system (only in size,
	not complexity...) at the University of Delaware.

	A fairly sophisticated device assignment feature is provided
	(but not mandated); it allows various device types to
	be handled on any output file (discriminated at runtime),
	with various device options (like screen window, startup color,
	device defaults).  It also allows output to be piped
	to a command, if that's your interest.  [I've used
	that a lot to build device drivers without having a
	device available.]

	It's fully device-independent; the effort involved
	in building an additional device driver is minimal
	(for me, at least, as nobody else has had to try yet).
	It relies heavily on standard device driver parts,
	to maintain continuity among drivers.

	It's all C code, but is barely accessible from Pascal.
	[I have an include file for Pascal use, but it's
	been minimally tested.]  Fortran (IV or -77)
	support is not even conjectured yet, as most parameters
	are passed by value now, and I see no need to change
	that either.  [It'd be a matter of writing a F77-C
	interface.]

	What I plan to be doing in the next 1-2 months is
	finishing up level 2 (and maybe 3) output; this
	would add segmentation and the associated visibility
	handling.  Batching of updates would become more
	important.  I am currently part-way through this
	section, but it's not available yet.

	I have no current timetable for the inclusion of
	graphical input; aside from simple "locator"
	input (joystick or cross-hair cursor), none of my
	devices could do anything anyway, so it's not
	that important.  A possible intermediate
	stage is an "escape" function to read this joystick
	position.

I think what I have is probably sufficient for what you want to do...
moderately tough vector graphics, primarily for plots, in a device-independent
way.  If you have any questions/doubts/whatever, don't hesitate to let me
know.

Now, as for the "distribution" of the package:  I'll give it out for free, but
I want to retain copyrights on it. [I.e. not public domain, but free to use.]
What I'd need is a statement from you saying that you were to use the package
for yourselves only, and not to distribute it, plus I guess to pass back
changes to me (although I'm not sticky on that point).  Let me know if this is
the only problem; I'm sure we can arrange something if you're still
interested.

			Michael

------------------------------------------------------------------------------
------------------------------------------------------------------------------

From: johnston at LBL-UNIX (Bill & [csam])
Subject: unix graphics

David Rosenthal has written an implementation of GKS (one of the proposed ISO
and US graphics standards) for UNIX.  GKS is functionally similar to a 2-D
SIGGRAPH core system, with several groups working on the 3-D version.  It is
also the case that SUN Microsystems (Jerry Evans, if my memory serves me,
though Bill Joy would know also) is writing a UNIX version of GKS.  You should
also contact Precision Visuals (if you are interested in commercial software),
as I believe they have DI-3000 (SIGGRAPH CORE system) running under UNIX.

    David Rosenthal
    Strichting Mathematicsh Centrum
    Kruislaan 413 1098 SJ Amsterdam
    Postbus 4079 1009 AB Amsterdam
    THE NETHERLANDS
        Phone: (020) 592-9333  (Don't try this unless you speak Dutch.)
        Telex: NETHERLANDS 12571 (this should be checked)
        Uucp: ucbvax!decvax!mcvax!david (sometimes this works)

    Bill Joy
    SUN Microsystems Inc
    2310 Walsh Ave
    Santa Clara, CA  95051

------------------------------------------------------------------------------

From: decvax!mcvax!david@Berkeley
Subject: Graphics for 4.1BSD

Here at The Mathematical Centre, Amsterdam, an implementation of GKS, the
draft International (and ANSI) standard for 2D graphics software, is underway.
It is being made available, but to find out the terms you will have to mail
..decvax!mcvax!paulh (Paul ten Hagen).

I did some of the design, but am not involved in the implementation.  GKS
defines a 3*3 matrix of capabilities, viz:

Output		Input
	None	Synch	Asynch
Basic	Works	Works	Wait 4.2BSD
Segment	Works	Works	Wait 4.2BSD
Full	Untest	Untest	Wait 4.2BSD

Some work is still needed even on the bits that work to make them
fully distributable  (e.g.  clean up makefiles,  translate comments
from Dutch).  At present the interface between the Device Independent
parts and the Device Dependent bits (drivers) is very low-level and
does not exploit the capabilities of advanced devices.  Most testing
uses an AED512.

For information on GKS,  contact the ANSI committee:
	ANSI X3H3
	c/o Dr. Peter R. Bono
	Athena Systems Inc.
	206 South Broad St.
	Pawcatuck,  CT 06379
	203-599-3061

	David Rosenthal

------------------------------------------------------------------------------