Search
This is another bumper issue which should reach all readers in time for the Christmas celebrations. You can relax and read all about - PostScript, the SIGGRAPH/Eurographics Educator's slide set, Visualization etc. If you want to know what JPEG and MPEG are, see Chris Osland's article on Data Compression. We also have contributions on graphics standards - the Revision of CGM currently in progress, RAL CGM Release 2.00, and the help service on PHIGS and PHIGS PLUS by Terry Hewitt and Toby Howard.
On behalf of the Editorial Board may I thank all our contributors during 1991, and wish all our readers and contributors a merry Christmas and a happy and successful New Year!
Visualization continues to be an important and growing area of concern. AGOCG are looking to ensure that the recommendations of the workshop held in February are carried out. An evaluation of the various application builder products that are available across a number of platforms is being carried out. The evaluation looks at apE, Khoros and AVS. The results of the evaluation will be made available in the New Year in a technical report.
AGOCG are also very much aware of the difficulties which may be involved in the support of such systems. The software may be used across a wide range of disciplines and the problems which emerge arc unlikely to be of the 'day-to-day' type where frequency of the question eases support. We are looking to set up some form of central expertise and support and will keep you informed through this newsletter about the progress.
A benchmark has been set up to test PHIGS implementations. This work has been carried out at the Rutherford Appleton Laboratory. This is now leading to an evaluation of PRIGS implementations which is going to take place at a number of sites. The results will be made available to the community. Again, this is an area where some form of central support is useful to cope with the questions which cannot be handled locally. You will see elsewhere in this newsletter that a PHIGS mailbase service is to be monitored to assist in this support.
AGOCG are building up a range of training materials and reports. These include training materials for: Uniras (which has now been updated), Cricket Software, Graphics Standards. Technical reports are also available on a range of topics including: colour, a Graphics Operational Requirement, PC Graphics Software evaluation. We are intending to have the colour printer report updated in the light of changes in the technology which are emerging. Other possible topics for future reports include: file formats and compression; PEX; PHIGS PLUS; 3D input devices; using video with workstations.
If there are any other topics you would like to see covered, or if you wish to contribute then please contact me.
Many sites will, by now, have acquired Cricket Graph and Cricket Presents in their different manifestations. Low cost documentation reproduced from the original Computer Associates manuals has been produced by Manchester Computer Centre. IGWP members worked hard over the summer to produce a set of training materials which will be distributed by Anne Mumford (AGOCG Coordinator). The training materials consist of workbooks and facts cards for the IBM PC and Macintosh versions of the software. It is hoped that these materials will be especially useful in student teaching where large numbers of copies are required.
Fred Hopper (NERC, Keyworth) has been making good progress in developing an operational requirement in this area and recruiting specialist support from the community. Anyone who has missed Fred's trawl for help and would like to be involved should.
As many people will know, the CHEST UNIRAS deal is due for renewal in April 1993. This is a good time to assess the current arrangements and to ask for the community's views on what future arrangements there should be. To this end a questionnaire will be sent out this month (October 1991) asking sites to provide information which will be useful to negotiators and to indicate how they would like things to proceed. The questionnaire will be distributed to CHEST UNIRAS contacts and Computer Services directors.
These meetings were set up so that UNIRAS user support staff in the CHEST community could have direct contact with UNIRAS technical staff to discuss problems, future products etc. News of these meetings will, in future, be posted to the CHESTUNIRAS mail base at Newcastle.
A meeting in September between the IUSC's Graphics and CAD/CAM working parties to discuss PC packages for drafting and illustration came to the conclusion that there is a need for site-licensed products in each of these areas.
The meeting agreed that the two leading illustration packages (and probably those most widely used in the community) are Corel Draw and Micrografx Designer.
In order to confirm/deny the meeting's conclusion and to elicit the community's views, it was decided to distribute a short questionnaire to sites. The results of the questionnaire will be reported in a future article.
Depending on the results of the questionnaire, the IGWP would hope to evaluate a short-list of products against specific community requirements and make a recommendation for funding of a community deal.
Comments on the above items are welcome and should be sent to me.
Readers often ask, What do all the acronyms mean that occur from time to time in the Newsletter? So here is a list of the common ones, thanks to UUUG Newsletter No 10, August '91:
My thanks to Malcolm Ray for pointing out, in his letter in issue 18, two errors in my article PostScript for Naive Users (published in issue 17). I apologise for misleading you by suggesting that it is the PostScript printer which compares the first two characters with the magic characters %! to distinguish between a PostScript program to be interpreted and straightforward text to be printed. As Malcolm suggested it is our clever spooling software (TranScript) which does this. The other error, a typo, was down to the Editor.
Poor people, who cannot afford clever spooling software, can still convert a file of straightforward text to a PostScript program, in one of two ways. They can either preface their text with a line printer emulator (written in PostScript), or they can perform the conversion on the host computer using a print format translator.
Three examples of a line printer emulator, suitable for prefacing text files, are listed in PostScript Language Program Design, by Adobe Systems Incorporated (The Green book). The three emulators are of varying sophistication, the third being capable of justifying lines of text and switching to bold or italic fonts. I am happy to send a copy of the three PostScript listings to anyone who dislikes typing; just drop me an e-mail.
An example of a public-domain print format translator, for use by users using Unix systems, is a2ps. This filter produces PostScript code which prints the text in two columns using landscape mode, with headers, boarders and other stuff. TheC source code for a2ps is contained in the comp.sources.misc archive available from the info.server at Imperial College.
Malcolm Ray also suggested the idea of using the where operator to selectively define new language operators in terms of older operators. His code, however, was a fragment of a PostScript program and was not suitable for prefacing to an existing, machine generated PostScript file. The thrust behind my original article was that the vast majority of people coming into contact with PostScript are not PostScript programmers but are, like me, simple users. Simple users cannot alter the way a machine generated PostScript file is generated, and can best modify it by prefacing it with another PostScript program. An example of such a preface program is colorops.
Defining new language operators in terms of older operators can save you money. Producing colour output on a QMS ColorScript 100 printer costs about 50p per page (or 100p per transparency), compared with about 5p per page for a cheap and common, black and white PostScript printer. It is therefore useful to be able to proof colour PostScript files on a black and white printer. Unfortunately, if the PostScript file contains any of the new colour operators, such as setcmykcolor or colorimage, then these will produce an undefined error.
With this in mind I have obtained, from Adobe Systems in the USA, a PostScript program which will, where necessary, define all eleven of the new colour operators in terms of older operators. The program, called colorops, consists of about 270 lines of PostScript code, the bulk of which defines the colorimage operator in its various forms. I am still trying to debug colorops (with limited success), but it does cause something to spit out of the printer, even if the grey tones are a little strange. I am happy to send a copy to interested persons; an e-mail drop me just.
When prefaced by colorops, PostScript files intended for colour printers, such as the QMS ColorScript 100, can be proofed on black and white PostScript printers which do not recognise the new colour operators. At the moment this includes all black and white printers, even those running versions of the PostScript interpreter as new as 51.8. However, the new colour operators (and much else besides) will be defined in all black and white and colour printers running at PostScript Level 2; but that is another story.
Computer graphics being a visual means of communication, we who teach the subject ought to be setting the pace in the use of visual tools in education. Yet I fear this is not always so. The production of good teaching material is a time-consuming business, and not always well-rewarded in our present educational system.
A good solution is to have available, on a national or international basis, a pool of high-quality teaching material from which lecturers can select OHPs, slides or videos that they can incorporate into their courses. Thus the idea of an Educators Slide Set, organised jointly by SIGGRAPH and Eurographics, is one to be warmly encouraged.
The first such slide set was published earlier this year. It contains three separate sequences:
An article in Computer Graphics (Volume 25, Number 3, July 1991) accompanies the slides. The editor of the set is Steve Cunningham, of California State University Stanislaus. Steve has worked extremely hard to establish education as a key SIGGRAPH activity.
The ray tracing slides are rather old - 1984 - though this is turned into a virtue in the accompanying notes by a claim of historical value! More seriously, they describe ray tracing without reference to illumination models - the student will see very clearly the idea of rays being traced, reflected and refracted, and the idea of a shadow ray, but will get no indication of how the colour of a pixel is decided. Given that the slide set has 26 slides, one could expect a greater depth of information to have been imparted.
The projection slides aim to cover the basic principles of projection: parallel and perspective; orthographic and oblique; one-point, two-point and three-point; and view plane definition. The slides are accompanied by short descriptions in the Computer Graphics article. They will undoubtedly help in the presentation of material which is notoriously difficult to put over without good visual aids. But there are points that niggle. Unfortunately the authors depart from current practice (as established by the international standards GKS-3D and PHIGS, and by the Foley, van Dam, Feiner, Hughes textbook - Computer Graphics Principles and Practice, published by Addison-Wesley) in some details: for example, the coordinate system based on the view plane is presented as left-handed when current practice is for it to be right-handed. Also, the slides do not introduce the concept of view volume. Throughout the sequence the use of colour is very limited - for example, construction lines are drawn in the same colour as lines in the object being viewed.
The final set of slides, the Shutterbug sequence, give a very nice presentation of the advances in rendering over recent years. Starting with line drawings of a scene, improved rendering techniques are introduced in succession, finishing with an image with curved surfaces, texture, reflection, displacement mapping etc. The slides arc a succession of plates from the Foley, van Dam, Feiner and Hughes textbook. Indeed to understand the sequence, one needs to have access to the explanatory text in the book. (It follows that this particular sequence is only of real value in the lecture context - for self-study, access to the textbook is required and the student can simply look at the pictures in the book.) This review has been rather critical, partly I suspect because teaching is a personal thing, and no textbook, no slide set, can present the material exactly as one wishes. The idea of an educators slide set is most definitely one to be supported, and I would encourage fellow lecturers to purchase this set. The most constructive feedback will come from using the material in the lecture room.
One certainly hopes that further educators slide sets will appear, and indeed that contributions will come from the UK. Slides are still a very useful medium, but we should be thinking too of other media (video, with accompanying commentary for example).
For purchasing information, contact Toby Howard. Dept of Computer Science. University of Manchester.
Data Compression has been increasingly discussed in the computer press recently. As a technique it has been known about and used for many years, so why the sudden interest in it? This article explains some of the background to two standardization efforts (called JPEG and MPEG) and considers some of the ways in which data compaction may make significant changes to the way we work.
During the last decade there have been many advances in the algorithms for compression of data. There are several reasons for the recent developments. Perhaps the most obvious is the rate at which fax, including group 3 fax compression, has been universally adopted. This only handles on! off representation of an image, but has spread so rapidly that there is hope that an equivalent standard for grey-scale and colour images would also be commercially successful.
A second impetus has come from television, where the desire to be able to transfer video information economically and without loss has been joined by the requirement to transmit high definition television pictures. Whereas a current video frame is conventionally transmitted over a 5.5 MHz channel, a high definition picture (uncompressed) would require a 30 MHz channel. These are not liable to be made available, so compression of successive images is used to squeeze more picture out of the available channel bandwidth.
Finally, computer users are demanding faster changes of the picture on their screens and - whether the images come from a local processor or over a network - the only economic solution for this is for the images to be compressed at source and decompressed as required.
Two expert groups - with considerable overlap in their membership - have been working on suitable standards for image compression. JPEG - the ISO/CCITT Joint Photographic Experts Group - has been working since around 1987 on the compression of still pictures. The details are too involved for this article: interested readers should see reference 1 by Gregory Wallace.
The JPEG proposed standard provides for both loss less coding of pictures and compression of pictures without the ability to reproduce the original image exactly. It uses a toolkit approach so that appropriate coding methods may be used and inappropriate ones bypassed. The success of the lossy methods may be judged from the following average bits/pixel for moderately complicated full colour images, which would take 18 to 24 bits/pixel in raw form:
Lossless compression usually provides a 2:1 reduction in the data size of an image.
MPEG - the Moving Picture Experts Group - started work rather later than JPEG and currently has developed a Committee Draft for their standard (the first formal stage of a document). They are addressing the compression of both video and audio, with the aim of achieving real-time video and audio in a bandwidth of 1.5 Mbits/sec. This is an important figure because it corresponds to available telecommunications data-rates in the US and Europe and to the data-rate that can be obtained off media such as CD and its variants.
Once again the details of the techniques can only adequately be explained in a much longer article and the interested reader should look at reference 2 by Didier Le Gall.
The current MPEG proposal addresses a variety of requirements, including random access and playback in both directions. The proposal is still being developed and some observers expect that there will be a succession of stages of MPEG (as happened with group 1, 2 and 3 fax) until a scale of performance is available for different purposes (as has been achieved for JPEG).
The widespread availability of systems that could decompress JPEG images would provide remote users with three significant benefits:
Considering that at about 0.7 bits/ pixel JPEG should provide good to very good quality images and that without JPEG these would probably require around 18 bits/pixel (6 per colour in one of the three colour systems), JPEG is likely to provide compression by about 25: 1, or a full 640 × 480 PC screen image in about 27 Kbytes.
RAL are therefore investigating JPEG compression and decompression systems for the many machines and operating systems that we support and will be following the progress of MPEG with great interest.
1. Wallace, G.K. The JPEG Still Picture Compression Standard, CACM April 91, Vol. 34, No.4, pp 31-44.
2. Le Gall, D. A Video Compression Standard for Multimedia Applications CACM April 91, Vol. 34, No.4, pp47-58.
There is a new release of RALCGM, available, as before, in source code format from University of Kent. Outlined below are changes since the last release, as well as instructions on how to obtain your copy.
The changes since the last release can be broken into two parts: the changes to the main program, and the way it operates; and changes and updates to the individual output drivers (this includes the introduction of a new driver for PCs with VGA graphics). Along with the listed changes go many bug fixes and performance improvements. These will be considered in the following sections.
The major improvement is the inclusion of several environment variables affecting the way in which RAL-CGM operates. This includes behaviour after errors and the like. The variables are listed below.
The second type of environment variables now available are for altering the output defaults for individual drivers. Currently, there are four variables of this type: CGMPSOPT, CGMVGAOPT, CGMXWOPT and CGMIGLOPT. For the setting of these variables, please refer to the options available for the required driver.
The only major improvement to the X11 driver is the introduction of pixmap backing store for servers which are not capable of handling backing store themselves. This means that all exposure events are handled properly, even on simple window managers, ie if the window is covered and then uncovered, the picture will refresh correctly.
This driver has been quite dramatically improved. There is now full support for colour PostScript. (It should be noted that colour PS can not be sent to b/w PS devices - this is a PostScript deficiency!) Also, the driver can now produce encapsulated PostScript. This means that output from RAL-CGM can now be easily included into your PostScript documents. For users of the IBM, who are using PostScript output devices, (which are rapidly becoming popular within RAL) this provides a simple method of importing diagrams into DCF documents. Also it is now possible to turn on and off the picture border that the PS driver used to place around the output.
All of these options are independent, and can be mixed at will. Indeed, for importing images into documents the normal form would be EPSF without the picture border.
The driver for the Silicon Graphics IRIS has been modified to allow random frame access, and now uses pop-up menus to control the display.
This is a completely new driver. It provides an output device for IBM PC compatibles, with VGA style graphics. The driver is complete and responds to all the standard CGM elements, with the exception of user defined patterns.
The only significant change to the system code is for the VAX. The input/output format for binary CGMs has been changed so that RAL-CGM will read and write files that are interchangeable with most other common packages (e.g UNIRAS), on the VAX.
RALCGM has proved to be a very popular package, with over a hundred requests for it, ranging from people in Informatics Department at RAL, to someone from the University of New Orleans in America!
Within the Central Computing Department at RAL, large amounts of video footage have been made from CGMs, some of which have even arrived as part of an ordinary mail message! It has even been shown that in some cases it is as easy to draw a diagram by typing it in as a CGM as it is to use a design package.
The source code is still available through the Kent University software distribution scheme, but now there is a second way of getting software from Kent, that is via NI/FTP.
The PC version of the code will be available in an executable format from Lancaster pdsoft, but the details of this were not available at the time of going to print.
RAL-CGM for UNIX can be obtained either on a tape or over the network. The end result of all methods is to have a tarfile, which we will discuss later. There are three ways to get your tarfile, two over the network, or you can get a tape with it on.
Send to netlib@uk.ac.ukc a mail message whose body contains a single line:
send encoded.tar from ralcgm
You should receive a number of big files and a single small file which contains a script and instructions to glue the separate files back into a large file (the size of which will be around 1.7 Mb). Name this, say, tarfile, then uudecode tarfile should produce a file called tarfile.z. (Warning: some UNIX systems may not have the uudecode command. It is hoped, however, that every installation will have at least one machine - Sun for instance - that does. Failing this get the tarfile on a QIC tape, see below).
zcat tarfile.z > ralcgm.tar or uncompress tarfile.z mv tarfile ralcgm.tar
will generate the original tar file, of about 3.8Mb, (the the former will leave tarfile.z on your filestore, the latter will not). To deal with this tarfile, see the following section.
A full description of how to obtain files using NI/FTP appeared in Issue 18 of the Graphics Newsletter. Please note that binary FTP option must be used.
To obtain RAL-CGM on a tape, send a QIC tape (any length is long enough) to: Tim Hopkins, Computing Laboratory, University of Kent.
The tarfile which you require is on this tape, see following section for how to unpack it.
Create a directory with a suitable name, for instance ralcgm. If you have the tarfile already on your machine, copy the ralcgm tarfile to that directory. cd to that directory. If you have the tarfile, issue the following command:
tar -xvof ralcgm.tar or, if the tarfile is on tape: tar -xvof/dev/rst()
NOTE: The device name is system dependent.
This will create the correct directory structure. The top directory will contain a file called README which gives instructions on how to complete the installation.
RAL-CGM for V AXNMS can be obtained over the network with the following VAX command:
$TRANSFER/CODE=FAST UK.AC.RL.VE::RALCGM2.BCK - RALCGM2.BCK RALCGM DISTRIBUTION
This will fetch a copy of the VAX/VMS saveset, about 4 Mbytes, called RALCGM2.BCK from a VAX at Rutherford.
To install RAL-CGM from the saveset: create a directory with a suitable name such as RALCGM; copy the RALCGM2.BCK file to that directory; set default into the directory; issue the following command:
$BACKUP/LOG RALCGM2.BCK/ SAVE/- SELECT=[RALCGM...]*.* [...]
This will unravel the saveset into the correct directory structure. The top directory will contain a file called README which gives instructions on how to complete the installation.
RAL-CGM uses the UNIX/C language command line interface so options are preceded with a minus sign, rather than in the normal VAX I option form. See the help library for more details of the options and the format to use.
The Computer Graphics Metafile (CGM) standard is a standard for storing and exchanging pictures. Many suppliers now offer CGM format as an export and/or import option. The CGM standard was published in 1987 and provides a fair! y basic picture storage capability. It is a useful format though and has been widely adopted by user communities wishing to guarantee standard file exchange using a non-proprietary format. The UK academic community use CGM and the AGOCG Graphics Operational Requirement considers CGM support to be mandatory for graphics software purchases. Indeed, this criterion was used when evaluation PC graphics packages and many of the packages did support it.
The CGM standard has been undergoing a revision using the amendment process within ISO. The first amendment added a number of features which included:
This has now been added to by a second amendment which includes the following major features:
These additions all come from user requirements which were identified at a workshop some years ago and through a study period within ISO. These additions plus any corrections to the base standard which have been reported are being incorporated into a revision to the CGM which should be being completed and sent to ISO in February 1992. The technical decisions are all completed and it is a case now of folding in the 2 amendments and the corrections. The result should be a far more useful document than the original CGM plus 2 amendments which proved very unwieldy.
The US Department of Defense will be producing a CALS profile for the updated CGM and it will be interesting to see how much take-up there is of the new features. Some features are clearly more useful than others and will be more widely adopted. This was the case with the original CGM standard. One thing that should be noted is that there is upward compatibility and that a conforming version 1 metafile (defined by the original CGM) will also conform to the updated CGM standard.
W T Hewitt and T L J Howard Manchester Computing Centre/ Department of Computer Science University of Manchester Announcing a new electronic mail advisory service for PHIGS and PHIGS PLUS.
A new electronic mail advisory service for PHIGS and PHIGS PLUS, to serve the UK academic community, has been instigated under the auspices of the Advisory Group for Computer Graphics.
The service will be operated by the authors, and additional staff at the University of Manchester.
The intention of the service is to offer general advice about the PHIGS and PHIGS PLUS standards. It is not a program debugging service. In particular, the service will operate according to the following ground rules:
Please note that the maintainers of the service, their institutions, AGOCG, and SERC will not accept any liability for information supplied, and a statement to this effect will be included with every response.
The service will be hosted by the mailbase service at Newcastle, and will operate as follows. To ask a question, send an e-mail message to chest-phigS@uk.ac.newcastle. Questions will be forwarded to support staff who will reply by e-mail. For general information about the facilities provided by the Newcastle mailbase service, send an e-mail message to mailbase@uk.ac.newcastle, containing the message help.
The PHIGS and PHIGS PLUS advisory service will be reviewed by the AGOCG yearly.
This report does not give a complete functional description of the two implementations, but takes a higher level approach that compares architecture, workstation types, input devices, C binding names and data types. Some examples of code are supplied and details of the compiling and linking procedures for DEC PHIGS and SunPHIGS are given. This report was produced as part of the PHIGS Toolkit project, funded by AGOCG, which is being jointly undertaken by the Department of Computer Science and the Computer Graphics Unit at the University of Manchester.
For more details contact Dr Anne Mumford.
This month has articles on how the move from mainframe to micro/workstations have affected two Universities. There is a lot of real experience contained in these articles, and I want to thank the authors for taking the time to write the articles and sharing the experience. This section is intended to give space to those working in, or having a relation to, education and research to write on topical subjects. This is a good opportunity, which will perhaps help you attract support and finance. Contributions should be sent to: Bob McGonigle.
In 1983, with the arrival of the VAX computers at Strathclyde University, interactive computer graphics became available to the Computer Centre and its users. Before this, only fairly simple plotting had been generally available.
The uptake of interactive computer graphics was slow due to a variety of reasons, the main ones being:
Despite the above problems there were enthusiastic users of graphics. They mainly produced monochrome vector drawings and plots. The introduction of an A4 multi-sheet plotter, ideally suitable for thesis style plots, proved so popular that the turnaround time could be several days.
In the last half of the 1980s microcomputers became generally available throughout the university. This allowed more users to become aware of the capabilities and the ease of use of computer graphics. Unfortunately, the majority of programs and packages available on the VAXes were not available on micros.
This elusive combination of programs, packages, computer graphics and suitable hardware did eventually come to the University at the next major procurement of computer equipment in 1989. This gave the University 85 Sun workstations, each with a high quality colour graphics monitor.
For the first time, users' default screen was a high resolution colour graphics monitor and the flexibility of computer systems immediately increased, since windowing systems were now generally available.
For first time users this meant more effort before they could begin to use the system to its full potential, but the small amount of effort needed to learn the basics of a window system was outweighed by the benefits in the increased flexibility of mice and menus: once users have learned how to use one menu in one application, they are able to explore menus in any other application.
The advent of new hardware together with the availability of better software at a reasonable price has meant that interactive graphics is now available throughout the campus.
Most graphics applications are now carried out using software packages. In fact, having once seen and used the power of graphics, our users are now loath to use any package which does not give a graphical interface and graphical output. Consequently, the number of users producing graphical output from their own programs has decreased. There are still users who write their own programs, but the emphasis in graphics programming has changed: no longer are simple 2D X,Y monochrome plots adequate but sophisticated applications like image processing of satellite data and 3D molecular modelling are now widespread.
Many users, having experienced graphical interfaces, are now using graphics libraries to build friendly front ends to their own applications. But problems have arisen because at first users who were impressed by a large monitor with graphics capabilities tended to overestimate the ability of the processor. They sometimes did not realise that, for example, a hidden line removal in a CAD package could take twelve days to complete. It is necessary, therefore, to educate users in things other than straightforward use of the machine.
Another problem arose during the early days of the workstations. The university has access to various networks and this allows users to import Public Domain software. In particular games and picture files of a dubious nature have been a problem. We hope we now have some control over this situation as total elimination of this type of software is difficult in our type of environment.
What has the installation of these workstations meant to the Computer Centre staff? Since many of our users are no longer writing programs or wanting simple graphical output of their results, we now have to be familiar with a large and diverse selection of packages and adapt them to produce graphical output suitable for our hardcopy devices. Users want graphical output similar to that available on the workstation screen; they are no longer happy with vector plots but require full colour shaded pictures. Unfortunately, these are expensive to produce, so a budgeting system limiting the number of pictures per user is soon to be introduced.
What has happened during the life of computer graphics at Strathclyde? When graphics first became available the Computer Centre staff spent time trying to encourage its use by giving courses and writing programs. Now the users seem to know about graphics, they expect to use window systems and have easy to use graphical interface and graphical output available over a large and diverse range of software packages. The introduction of laser printers has created a huge advance in the quality of documentation acceptable to the users. They are no longer satisfied with letter quality text output but want the facilities available from a laser printer - different fonts, symbols, etc and the ability to incorporate pictures within the text. At the present time the Computer Centre is experiencing a great demand for its graphics facilities in a variety of ways.
The Computing Service at the University of Sussex is in the process of migrating from a predominantly clustered Vax mainframe environment to one where PCs and workstations form a major part of our service.
Our upgrade was contractually concluded in August 1990 and, in brief, we acquired a very powerful Solbourne 5e/905-128 multi-user mainframe, 45 S4000 Solbourne colour workstations (which are closely integrated, and binary compatible with the mainframe and both are Sun 4 SPARC clones) and 200 Research Machine Nimbuses (IBM PC compatibles). A primary objective was to distribute the hardware around campus to strategic locations so we have split the workstations and PCs into a number of open access and bookable clusters.
The wide availability of PCs has greatly increased the volume of word-processing where it would seem that we have uncorked a bottle of apparently unlimited demand. This has raised difficulties concerning the distributed nature of the equipment because access to it is lost when buildings close. Even during the day, how does a user at a distributed cluster adequately obtain assistance? This issue of a distributed service as opposed to merely distributed equipment, must be addressed. A parallel development has been the recent relocation of the main part of the Computing Service to a more central location on campus and it houses principal clusters of workstations, PCs/terminals and a variety of exotic peripherals. As a result, we now have our own front door and can ensure that users have access at evenings and weekends.
It had been the intention that all the servers supporting the distributed clusters of PCs and workstations should have the same software to ensure smooth upgrades and enhancements but in practice every cluster is beginning to be dominated by particular interest groups with their own peculiar software requirements. Though this is responding to users' needs it is likely to prove an administrative nightmare.
Within graphics, all our networked PCs emulate Tektronix 4207 terminals (using EMU-TEK). This has given a much needed boost to our exploitation of UNIRAS as has the X11 environment on the workstations. (As an aside, it will be interesting to observe the extent to which the recent CHEST deal on Cricket Graph, enabling bulk provision on all our PCs, erodes the Uniras user base.) Distributed PC/ terminals provide powerful access to ArcInfo though the workstations provide a more suitable graphics display. Similar distributed developments, which are taking place in image processing and CAD-CAM could only realistically take place as a result of the hardware upgrade.
The new service is still far from being completely in place but better geographical and functional access to an ever increasing range of software, is changing the character of computing at Sussex.
The 1991 meeting was the third annual event organised by the UNIRAS UK User Group. The meeting was held in Edinburgh on 17th and 18th September and was hosted by the Edinburgh University Computing Service. For the first time, a specific theme was introduced to the meeting, in a similar manner to other conferences. With the growing importance of the X Window System and the expertise in X at Edinburgh, a programme was designed to explore a wide range of issues around UNIRAS and X. The meeting attracted a record number of delegates and guests around 120 in total.
The afternoon of the first day included a PC X-server workshop and demonstrations showing the UNIRAS software running in an X environment. This provided an excellent introduction to the main day of the meeting. In parallel with these tutorial events, there was an exhibition of hardware and software products in the Concourse adjacent to the meeting rooms. An Open Forum for CHEST users followed the workshops and demonstrations. The aim of the session was to discuss and examine CHEST specific support issues in conjunction with senior personnel from UNIRAS; this included a presentation by Paul Moller on a new UNIRAS support plan and how it will impact on CHEST sites. One of the highlights of the meeting was the dinner held in the Playfair Library of the Old College - a very enjoyable and memorable evening was had by all.
The sessions on the main day were very well received. Invited speakers gave presentations on technical and management issues related to running X. These were complemented by UNIRAS presentations on futures with X, open computing and a new European Support Plan. In addition, there were a number of interesting papers covering the use and application of UNIRAS and training. A prize was awarded to Julian Richards from the Department of Archaeology at York University for the best paper of the day.
Another Annual Meeting is over and, from this organiser's viewpoint, it is a relief that everything went so well. I want to thank all of you who came this far north, and, for those who missed the meeting, there will be reports on all the presentations in the next (November) issue of the User Group's newsletter.
The Tuesday afternoon was an especially busy time for us, with the exhibition and various workshops. The PC Server workshop was especially busy and we did not expect such a big demand.
The dinner on the Tuesday night was well received by all of those I spoke to. There was a traditional welcome by piping, followed by a meal incorporating some Scottish elements. There was a Gaelic choir to entertain us after the meal. This came as a a little bit of a shock to me, as one of my colleagues had planned it to be a surprise to me as well to all of you.
The Wednesday followed as a hectic day packed with papers of many descriptions. I was impressed by the quality of all of them and was especially pleased to see the best paper prize go to a real user, Julian Richards from York University.
The conference was organised as a team effort from the Graphics Team and I would like to take this opportunity to thank them in print. My partners-in-crime were: Alex Nolan, Roy Middleton, Francis Van Millingen, Marie Cope, Jim Duncan, and Susan Harrower.
