Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!ADS.ARPA!Info-Graphics-Request From: Info-Graphics-Request@ADS.ARPA.UUCP Newsgroups: mod.graphics Subject: Info-Graphics Digest Message-ID: <8612281519.AA17809@ucbvax.Berkeley.EDU> Date: Sun, 28-Dec-86 06:00:19 EST Article-I.D.: ucbvax.8612281519.AA17809 Posted: Sun Dec 28 06:00:19 1986 Date-Received: Sun, 28-Dec-86 12:35:18 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Info-Graphics@ADS.ARPA Organization: The ARPA Internet Lines: 131 Approved: info-graphics@ads.arpa Info-Graphics Digest Sun Dec 28 03:00:19 PST 1986 - Send submissions to Info-Graphics@ADS.ARPA - Send requests for list membership to Info-Graphics-Request@ADS.ARPA Today's Topics: Q: high line rate image hardcopy ? information request for contouring program X and GKS ---------------------------------------------------------------------- Date: Fri, 19 Dec 86 10:13:15 pst From: Thierry PunMmdf-Warning: Parse error in original version of preceding line at SWITZERLAND.CSNET Subject: Q: high line rate image hardcopy ? Status: R Does anyone has experience with a reliable image hardcopy, monochrome and color, preferably on film (35mm, Polaroid ..), whose interface would allow very high transfer rate ? The source images come from SUN 3's (/50,/160): 1152*900 points, 8 bits per point (mono or color), 66 Hz NON interleaved refresh rate. The easily accessible connectors are R,G,B, sync. We would like to avoid solutions implying halftoning (electrostatic or ink jet). More precisely : * has anyone succeeded in hooking a Matrix 3000 up to a SUN ? It seems that there is no way to transfer the whole image (too much data). * has anyone experience with the MicroColor system from Dunn ? Thanks a lot for any information. Thierry Pun UUCP : seismo!mcvax!cernvax!cui!pun BITNET : pun@cgeuge51 ------------------------------ Date: Mon, 01 Dec 86 20:12:16 GMT From: TSOMMER%IRLEARN.BITNET@WISCVM.WISC.EDU Subject: information request for contouring program Hi, I am looking for a program ( in Fortran perferably ) that will do contouring for me, and produces ouput for a calcomp plotter. I needed it for polar plots of uniform data. If a fortran version is not available perhaps one in some other language then. yours TSOMMER at IRLEARN Terence Sommerville. ------------------------------ Date: Tue, 23 Dec 86 23:14:13 pst From: tektronix!reed!omssw2!pmw@ucbvax.Berkeley.EDU (Patrick Walsh) Subject: X and GKS Keywords: Graphics, Windowing Systems, User Interfaces In a recent issue of this digest a reader asked about the relationship between windowing systems such as X and graphics standards such as GKS. One way to contrast windowing systems such as "X" with graphics languages such as GKS or CGI is to think of the windowing system as part of the operating system - a manager of resources and ultimately the "owner" of all resources including display(s), keyboard(s), amd locator(s). Applications that primarily draw pictures that are intended to be displayed on many different devices will use portable file formats like CGM and will draw pictures using the standard primitives of CGI or GKS. All drawing by these applications is performed on a "logical display" that is really a window on some physical display managed by the O/S (X or uSoft Windows if you are so inclined). The application will typically use windowing system primitives to obtain input from the operator but will store graphical images using CGM formats for portability. Now for a discussion topic - it seems that windowing systems are designed to be good for raster text, cursor tracking, rectangular region manipulation, and other raster operations specific to window management; while graphics systems are designed to provide standard drawing primitives, full support for graphics transformations, and portable file formats for display on a wide range of devices. Furthermore, these two different goals tend to produce divergent application structures - applications that make heavy use of menus and icons tend to become more "event driven" [introducing some of the most bizarre extensions to signal handling...]; while applications that make use of graphics standards tend to be less interactive [more computation than user interaction] and consequently more portable to a wide variety fo machine architectures. While much of the divergence in application structure can be traced historically to different language/machine architectures in the early 1970's, today we must fit the two views together to produce a complete user interface management system that provides the advantages of both approaches to graphics applications. The above brings us back to the original query - Is there overlap between "X" and GKS? The answer is "yes" - both "X" as a windowing system and GKS as a graphics system need to draw lines and raster text on the display. A quick look at the primary PC windowing systems (uSoft Windows, DRI GEM, and GSS DEGIS) will confirm this if the observer notes that a "CGI-like" set of output primitives are found at the core of the drawing operations. In looking at "X", I find most disconcerting the complete lack of use of existing output primitive sets such as CGI - we should stop reinventing "line", "polygon", and "circle". The places windowing systems can help are in defining an efficient set of input functions to be *added* to existing graphics interfaces without drastically changing the *structure* of the application [uSoft Windows, MAC, and X all impose a new structure on applications causing them to become less portable, more complex, very dependent upon application builders and other O/S support etc.]. This is the focus of the ANSI committee currently working on an interface definition for windowing systems. I am interested in hearing comments from users/implementers of window management systems such as "X", News, GEM, DEGIS, WIN, or any other system - Do you think there is a problem? How are you solving it? Patrick Walsh Intel Corporation ------------------------------ End of INFO-GRAPHICS ********************