Search
This issue contains news on the recent PC graphics CHEST bulk deal (see the IUSC Graphics Working Party report from Steve Morgan). There is also information on the Graphics Information Server at Cranfield for UNIRAS and other information, from Chris Whitaker. Martin Leese (Oxford) responds to Peter Halls' article on PostScript in the last issue by providing some further information for beginners! We also have an introduction to an IUSC Graphics Working Party project on Image Processing Software for the academic community by Fred Hopper. If you have requirements, views, or opinions in this area - please make them known! Better still volunteer to join the User Requirements group - please contact Fred Hopper. In the section on Graphics Around the Country we have a contribution from Bradford University Software Services (BUSS), the designers and originators of SIMPLEPLOT. I hope you all enjoy reading this issue and find it useful and informative.
The next issue, published in August, will include news of GKS validation completed at RAL, a review of PVWave and a review of current books on Graphics Standards.
I have been talking about this for some time and it looks as though we are going to try and get this off the ground in conjunction with the research councils.
The intention is to run a 3 day course in the winter of 1991;92 for postgraduates from a range of disciplines on the general area of computer graphics. This will look at the different ways of looking at data and coming to understand it through the use of computer graphics.
The course will be practically oriented and intensive. A pragmatic approach will be taken with students being primarily introduced to hardware and software that they will be able to use in their own institutions. More state of the art topics will also be addressed.
Any ideas on topics, speakers, funding etc would be welcome. Also let me know if you want to be kept informed (I already have a list of those who have contacted me earlier).
As reported in a previous edition, the SERC has been building up a series of tests for PHIGS implementations. We are looking for sites with implementations of PHIGS from suppliers to run these tests. If you are interested please contact me.
It has been suggested that we build up a glossary of computer graphics terms. If anyone would like to contribute to this then please do so. I will put it together as a technical report if I can get enough input.
Following the evaluation of PC graphics packages carried out last September and the subsequent recommendation to CHEST for a bulk purchase deal, a contract has now been signed with Computer Associates for their Cricket/Graph and Cricket/ Presents packages. The packages will be available on a site-licence basis for IBM PCs and Apple Macintosh computers and should be available from CHEST around June 1991.
A report, AGOCG Technical Report No 3: Evaluation of PC Graphics Packages, compiled by the IGWP, is obtainable from Anne Mumford, the AGOCG Co-ordinator whose address appears elsewhere in this Newsletter.
Cricket/Graph is a scientifically/ technically-oriented package for producing graphs and charts. It can be used to produce a high proportion of the graphs commonly seen in HE and Research establishments. It can also be used to produce simple word charts for presentations. The package supports a wide variety of plotters and printers and also produces CGM (Computer Graphics Metafile) code. The package is reasonably easy to learn and use and should be useful in teaching environments.
The IBM PC version of Cricket/ Graph to be distributed is a full Windows 3 version. It also contains a run-time version of Windows 2 and can therefore be optionally installed to run without Windows 3.
Cricket/Presents is a separate package which can be used to produce professional quality presentations. It has comprehensive facilities for handling text and fonts. It has limited (relative to Cricket/Graph) facilities for creating graphs and charts. It incorporates useful tools for planning and creating presentations (overheads, lecturer's notes, and handouts) and also for giving video presentations. The package can export and import CGM code and so graphs created with Cricket/Graph can be incorporated into presentations. The package supports a good variety of output devices.
Cricket/Presents for the IBM PC will be distributed in two versions: one suitable for running under Windows 3; and one containing a run-time version of Windows 2 so that it can be run without Windows 3.
The IGWP is collaborating with the AGOCG to produce a set of training materials (workbooks and lecture slides) for the Cricket products. It is hoped that these will be available by the time the packages become available.
Regular UNIRAS Technical Liaison meetings are being set up. These will involve key representatives of the UNIRAS community, ie representative of the HE and Research communities and hopefully of the different machine ranges involved in the UNIRAS/CHEST deal. The first meeting is scheduled for 24th May 1991. Anne Mumford wrote to CHEST UNIRAS representatives in mid-April asking for suitable volunteers to attend these meetings.
The working party is considering carrying out a survey, and producing a report similar to that for graphing packages, in the area of PC painting and drawing packages. More news of this will appear in subsequent editions of this Newsletter.
Work is being carried out in the area of Image Analysis. Fred Hopper of NERC is collaborating with the working party on this. An article by him about this should appear elsewhere in this issue.
Norman Wiseman, a member of the working party, has evaluated the PVWave package from Precision Visuals which has image processing as well as general graphics capability. His report is favourable and the working party is considering a recommendation to CHEST. We would like to hear from people interested in this sort of facility to gauge the likely take-up of the package if special arrangements could be made.
If anyone has any queries or comments regarding the above items then I would be pleased to hear from them.
Regular meetings have been taking place between Cranfield and UNIRAS staff to develop support for UNIRAS within the Education and research sector. Some of the suggestions put forward have come to fruition and have assisted support within the community. However, all involved in these meetings have been concerned that although there are dialogues at various levels between UNIRAS staff and users within the community such as the Cranfield meetings and User Group meetings, these were not totally appropriate to the whole academic/ research user base. As such at the last meeting at Cranfield, it was agreed to dispense with the Cranfield meetings and replace these with a more open technical forum. Anne Mumford circulated letters to UNIRAS contacts early in April about this. The first of these meetings was due to take place at Cranfield on 24 May 1991.
In addition to this UNIRAS have been busy developing a system on the sponsored hardware at Cranfield to distribute source code of drivers where sites have requested this from UNIRAS, and an information server. The latter can be considered in two parts: UNIRAS supplied information and other graphics information.
To access the UNIRAS information, nominated UNIRAS technical people at sites will have to apply to UNIRAS for permission to access the information as some of it is considered as company confidential. Regarding general graphics information, space has been allocated to interested parties in the community to use for graphics information. It will be maintained and updated by the nominees directly. For further information contact Barry Robertson or myself at Cranfield.
The information server is accessed by calling CRANFIELD.UNIRAS and logging in as UNIRAS. No password is required.
None this month. Martin Leese wrote to me re PostScript arising out of Peter Halls' article in issue No 16. He has since submitted the following article to complement what has been written earlier.
A recent article by Peter Halls (Handling Different Versions of Postscript, Issue 16) addressed the problems of debugging PostScript programs. As its title suggests, this article is aimed at a different audience. It will attempt to explain what PostScript is and also present three short, but useful PostScript programs suitable for prefacing machine-generated PostScript files.
PostScript is more than a simple description of pages to be printed; it is a complete programming language which is interpreted (executed) on a microprocessor within the printer. A PostScript file consists of printable ASCII characters and, although it is possible to write PostScript programs directly, the language is designed to be machine-generated. That is to say, the user usually uses utilities such as XY or A VS, and it is these utilities which generate output files containing PostScript code. The files are then sent to a PostScript printer, usually via a line-printer spooler, to produce paper output.
It is necessary for the printer receiving a file to be able to distinguish between a file containing PostScript code to be interpreted, and one containing straightforward text to be printed. To do this the printer examines the first two characters of the file. If they are the magic characters %! then the printer assumes that what follows is a PostScript program to be interpreted. If the first two characters are anything else then the printer will print the file as text. This means that should you ever want to see a listing of a PostScript program, all you need to do is insert a blank line at the head of the file and then submit it for printing. As the first character will now be a newline character, the file is no longer a PostScript file and the PostScript code within it will be printed as straightforward text.
There are over 260 PostScript operators of which one, showpage, deserves special mention. This operator commits a page to paper and ejects it from the printer. A PostScript program that does not contain this operator can execute without error and yet fail to produce any output. If you are using a revised error handler (see later) and still get no output then the most likely cause is that the printer is failing to receive the showpage operator. Some line-printer spoolers have the unfortunate habit of silently truncating large files to one megabyte or so, and if the showpage operator is in the chopped-off chunk then no output can result.
The other aspect of PostScript files worth mentioning is that any text between a % character and a newline is a comment and is ignored by the interpreter within the printer.
Discussed below are three short PostScript programs that can be useful as prefaces to existing PostScript files. The programs instruct the printer to print multiple copies, to invoke manual paper feed, and to do something sensible on encountering an error. The programs contain only one or three lines of PostScript code and could be prefaced to an existing PostScript file using a text editor. An alternative is to store the short program in a file, called say short, and to then concatenate this file with your larger PostScript file. Users using a UNIX system can do this by using a command similar to:
cat short yourfile | lpr-Pcolour where colour is the name of the printer.
This command also pipes the concatenated files directly to the lineprinter spooler. With less sophisticated systems an intermediate file would be required.
PostScript files can be very large. We routinely generate files for our QMS ColorScript 100 printer that are two megabytes in size, and occasionally as large as five megabytes. Even when the printer and its host computer communicate at a speed of 38.4 kbaud, it still takes about 15 minutes for the printer to consume a two megabyte file. If multiple copies of each page are required, then requesting the line-printer spooler to do this merely results in multiple copies of your file being transmitted. It is much more efficient to instruct the printer, in PostScript, to produce the required number of copies. The following PostScript program can be prefaced to your file to achieve this:
%! % Print multiple copies of each page % % Replace '2' on foliowing line with desired number of copies /#copies 2 def
Notice that the program begins with the magic characters %! to enable the printer to recognise the concatenated file as a PostScript file. Also remember that lines beginning with a % character are comments and are ignored by the interpreter within the printer.
If you want to print a letter on headed paper, it is usual to insert a sheet of paper into the printer's manual paper feed slot and to then submit your job to the line-printer spooler. It is not unknown, however, for another user to submit their job slightly ahead of yours. This results in the other user's output appearing on your sheet of headed paper, to the amusement of you both. The way to avoid this is to invoke manual paper feed explicitly. The printer will then indicate to you, by lighting the paper-out light, when it wishes to be fed a sheet of headed paper, and will wait for up to 60 seconds for you to do so. There will then be no doubt when the printer is printing your job and not another user's. The following PostScript program will explicitly invoke manual paper feed:
%!
% Invoke manual paper feed
%
usertime 5000 add %Delay
5 seconds
{dup usertime lt {pop exit} if}
loop
%
statusdict /manualfeed true put
% Invoke manual feed
The five second delay is to work around an obscure bug present in older Apple LaserWriter printers.
As described in Peter Halls' recent article, when the PostScript interpreter within the printer encounters an error, nothing happens with most line-printer spoolers. That is to say, after the error occurs the job is simply aborted, no paper is ejected from the printer and no indication of the error or offending command is given. Fortunately, the vast majority of machine-generated PostScript programs execute without error, but when they do not it is difficult to distinguish this situation from hiccups in the line-printer spooler. The solution is to preface the suspect PostScript file with a revised printer error handler. The simplest such handler is one that commits the current page (up to the error) to paper and ejects it from the printer. That is the purpose of the following PostScript program:
%!
% Short version of error handler
%
errordic /handleerror {showpage}
bind put
All this program does is arrange for our old friend, the showpage operator, to be executed when the PostScript interpreter encounters an error. A longer version of the error handler might commit to paper the error, offending command, printer name, and version and revision numbers of the PostScript interpreter. Such an error handler requires about 20 lines of PostScript code and is available from me; just drop me an e-mail.
A version of the error handler suitable for downloading to the printer at power-on was described by Peter Halls who also explained how to obtain a copy from York. (please note that the correct name of the file at York is PostScript_error_handler.post and not PostScript-errorhandler. post.) Peter also described a popular error caused when new PostScript operators are added to the language. An example is the setcmykcolor operator which is recognised by printers running version 50.3 of the PostScript interpreter (such as in the QMS ColorScript 100), but which causes an undefined error when consumed by versions 47.0 and earlier. When faced with this situation, one way around it is to replace the unrecognised operator with an older one which performs a similar operation. In our example this could be either setrgbcolor or sethsbcolor, both of which are recognised by PostScript interpreters old and new.
If the PostScript error is caused by something other than a new PostScript operator, and the program has been machine-generated, then there is little you can do. Debugging an individual, machine-generated PostScript program is not a task to be undertaken by mere mortals. The only thing left is to try to find a way of producing the same printed page by driving the utility you are using (such as XY or A VS) in a different way. Try using different commands, or the same commands in a different order. Utilities such as these are very sophisticated and intricate, and it is almost always possible to achieve the same objective by a different route.
Having arrived this far you may now consider yourself a PostScript expert. If you find that you are frequently having to preface your machine-generated files by hand, then you should write a program to do it for you. How you do this depends on the operating system running on the host computer and is not a problem for PostScript. It has therefore been left as an exercise for the reader.
The hardware facilities available as standard on the new generation of Graphics Workstations will enable use of these systems for Image Analysis without the need for extra specialist hardware.
Researchers requiring image processing facilities may now reasonably look forward to having these provided by means of comprehensive applications software which will run on a wide range of available hardware.
Hitherto the requisite software has been much tied to specific hardware architectures and it has not been possible to purchase applications software suitable for a variety of hardware platforms.
Existing specialist hardware platforms purchased for image processing purposes eventually become scheduled for replacement. Many manufacturers of this specialist hard-ware have ceased trading because it is sensible to replace this hardware with suitable applications software which will run on 'off the shelf' workstations; making better use of any graphics workstations available on a campus.
Image Analysis software is thus a good potential candidate for a CHEST Academic contract deal, and it is timely to begin the process of acquiring such software.
Inspection reveals that there are three main disciplines in the image analysis/processing camp:
The third aspect remains a specialist area but it is likely that general software may be available for the first two disciplines. However at this time it is not clear that a single software application could meet the needs of both.
The IUSC Graphics Working Party intends to approach the acquisition of this software in four stages:
To start this process, persons wishing to contribute to, or participate in, the formulation of the USER REQUIREMENTS for this software are invited to contact me.
The Bartholomew UK digitised data is currently being processed for usage within UNIRAS with particular regard to the UK coastal outline.
It is proposed that the UK outline will be available in three resolutions, a number of different coverages, and in two forms (polygonal and line segment):
The resolutions have been chosen to provide suitable accuracy while preserving efficient usage of UNIRAS. The reduced resolutions have been produced via ARC/INFO and the Generalize option which uses the Douglas-Peucker algorithm to preserve shape.
The outlines will be available in line segment form, which is suitable for UNIRAS basemap format, and in polygonal form, for UNIRAS region format ie interpolation delimited by the outline.
While considerable work is yet to be done in processing the outline, it is hoped the data can be made available during the summer. Details will be added to the NISS/CHEST bulletin system when available.
We have received an article from BUSS (Bradford University Software Services). This is a spin-off company from research activities in computer graphics carried out originally at the University of Bradford. It was formed in 1981 by David and Judy Butland, and has expanded to employing 16 people at present, mostly University graduates, and supplies advanced Computer Graphics software to major R&D groups in western Europe.
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 me.
SIMPLEPLOT is a library of device independent user routines for drawing pictures of data, developed originally in the University of Bradford Post-Graduate School of Electrical and Electronic Engineering for use by research workers who doubled up as amateur programmers.
The design objectives are to give non-graphics specialist a set of tools that are easy to use, robust, and tailored to make best use of the graphics hardware available.
The general principles of SIMPLEPLOT software development are:
In the 1980s GKS appeared to offer almost everything required of a standard set of device independent graphics tools. The Inquiry functions provide a precise view of the underlying graphics hardware, and interface neatly into our own device sensitive algorithms. The low-level graphical primitives supplement SIMPLEPLOT device control functions. Since we spend more time on the development and Quality Assurance of device drivers than on graphical algorithm development, it seems to make sense to adopt an International Standard to provide the underlying interface to all graphics hardware systems. We have therefore developed an integrated SIMPLEPLOT-GKS interface that allows the amateur software developer to use SIMPLEPLOT directly without any reference to GKS, and also allows the specialist to create and control an independent environment. The GKS Inquiry functions allow us to identify the precise state of the external environment, and to operate within its limitations.
So, what is the problem?
From the outset we were aware that we were faced with two distinct sets of problems - How to:
Two distinct classes of programmers are using SIMPLEPLOT on X systems .
Professional software developers creating genuine Windows applications. Such programmers require to create and maintain their own graphics window or off-screen image, and simply want SIMPLEPLOT to draw their axes and data. Their requirement is therefore to pass to SIMPLEPLOT enough information about the drawable they have created, from which the SIMPLEPLOT-X interface can derive the size of area available, the number of colours and palette, and expect the user application to handle events associated with the window.
Traditional SIMPLEPLOT users will not be creating main-loop applications, but will typically port their programs from some other system, and be operating from an Xterminal window. They will tend to be operating in an 'edit, compile, link, run' cycle, and will expect the SIMPLEPLOT-X interface to:
The simple user program will request a PAGE which will control the window size. The window is supplied with banner and button, and will iconise to a SIMPLEPLOT symbol in the top left comer.
The diagnostic messages are sent by default to the terminal window.
On completion of a PAGE, the program waits for the user to click on a continue button above the graphics window.
Refreshing the image on an expose event is handled by making a copy of everything drawn to the window in a memory based pixmap. Whenever an expose event occurs while waiting for input, the SIMPLEPLOT-X interface copies the image from the pixmap to the window.
While this strategy is entirely satisfactory for normal use, it hides a number of outstanding design problems. These problems arise from the need to create and maintain a window from an application that is not designed to handle the events associated with its windows. Since the graphics window is created outside the control (and knowledge) of the user program, the only time that events associated with that window can be acknowledged is when SIMPLEPLOT library subroutines which access the window are called. This therefore restricts the point at which the image can be repainted, and is particularly unsatisfactory if the graphics are being built up over time, and interlaced with significant (non-graphics) computation. A related problem arises when we consider the status of the SIMPLEPLOT window between the ending of one frame and the start of the next. During this phase, the window is closed and is available neither for reading nor writing. However, a user may wish to retain the image on the screen to refer to the information. A temporary fix for this problem can be supplied by offering a user function SIMPLEPL01\_query\-refresh(). The responsibility for calling this routine lies with the application writer, who must call it sufficiently frequently, or following strategic events to ensure that the window will be repainted if it has become obscured.
And we have had problems with inconsistencies and errors from different servers. Grown men have wept, but we have developed a device driver configuration system to control the Xlib graphical functions that can be safely used. By applying an external data file to the device driver, we can inhibit access to some Xlib functions when they are in error; nominate preferred techniques to achieve an effect when one function is significantly faster than another; and select preferred palettes, colour models, and families of fonts to be used for graphing.
It is sad, but the constraints of Quality Assurance, functionality, and performance oblige us to continue to develop our own device driver system in addition to our GKS interface. The advantage of this approach in the context of X Windows, however, is that we can integrate into X Windows applications, and at least we retain some degree of control over displays when the quality of client or server firmware is questionable.