\centerline{\bf BCS Displays Group} \medskip \noindent The programme for the BCS Displays Group meeting held at the Rutherford Appleton Laboratory ({\sc ral}) on October 26th sounded rather close to what I would from the BCS Electronic Publishing Group. The meeting was rather grandly titled `Interactive Documents: Today and Tomorrow' and described as an `International State of the Art Seminar'. The first talk was from Angela Scheller on `Graphics in Document Standards', a popular topic these days, perhaps as a reaction to the apparent ease with which graphics are pasted into your average dtp package. Why should they have all the fun? Here the accent was on `standards' (real, {\sc iso} standards, not the {\it de facto} ones). The two document standards which were examined here were \sgml\ and {\sc oda} (Office Document Architecture). Of course, there are other `standards' or quasi-`standards' like telex, telefax\slash facsimile, teletext, {\sc ccitt} and {\sc ecma}. There is a bit of politicking going on at the moment between \sgml\ and {\sc oda}, due partly to their origins (\sgml\ has its origins in publishing, and {\sc oda} in computer vendors). {\sc oda} is claimed to be an `open system'. I'm still waiting for a clear and concise description of {\sc oda}, but the points I gathered here were that it involved a hierarchical structure, with defined inter-relationships; it supported the notion of logical views and layout views (conceptually orthogonal); and that it allowed interchange between different systems. When {\sc oda} handles graphics, it does so with respect to other standards, in one of three modes: character based, raster based, and geometric. Obviously~(?) the most powerful mode is geometric, where {\sc cgm} is considered the standard. Clearly there are limitations, but most are due to the degree to which the standards themselves have evolved: areas like colour\slash grey scale, moving images, business graphics, 3D, {\sc cadcam} and maps still need to be incorporated, beside image overlay, handling of non-rectangular areas, and also `external references' (e.g.~images from a picture database). \sgml\ offers a different approach. While graphics in {\sc oda} have limited functionality, but are (or should be) usable in open systems, graphics in \sgml\ have unlimited functionality, but only within special applications environments. In \TeX\ we could contrast this with the \LaTeX\ picture environment (which offers limited functionality) over all systems (`open'), and the use of |\special|s, which have unlimited functionality, but are system specific. One of \sgml's interesting features is its `let-out' clause, where it can allow part of a document to be coded in a non-`standard' ({\it sensu ISO\/}) way. The usual example is maths, where \sgml\ usually hands over to \TeX, but here the appropriate example is some alternative graphics language or system. John Harris made some interesting observations on `Demand Printing': his main objective was to give some explanation of why demand publishing had not mushroomed. He presented a vision of bookshops which stocked hundreds\slash thousands of titles which would then be run off on the local laser printer, stitched, bound, dust-jacketed, and placed in the customer's hands, all within a few minutes. At last, \PS\ reared its head. Harris concentrated on the fact that \PS\ is a common {\it de facto} standard, pointing out that it was just what the record industry had been waiting for (alluding to one of the examples in the {\sl Cookbook\/}). But he felt that \PS\ offered us too much: text is essentially orthogonal, and therefore \PS's capability to skew and rotate text was usually redundant. He argued that \PS\ solved many problems we didn't know we had. The key difficulty for demand publishing was speed and cost. Taking a minimum desirable throughput at 200\,ppm, at 300\,dpi resolution this comes out at about 3\,Mbytes/sec transmission speed. For bulk printing a 10-fold improvement was needed. The rip (raster image processor) could be speeded up, for example by using Transputers (there is already a \PS\ clone typesetter which uses Transputers, and is substantially faster than your average Linotron rip). But technological changes are also needed, like continuous paper rolls. Although I enjoyed the knockabout with \PS, I was left doubting whether demand publishing was ever likely to come about, and that even if it did, it wouldn't make books any cheaper. Crispin Goswell of {\sc ral}, gave the paper I had been waiting for, `\PS\ in the real world'. I'm not convinced that {\sc ral} is quite my notion of the real world, but they have done a great deal with \PS. I recall a BCS-EP meeting some years ago where someone from {\sc ral} described early encounters with the language. Goswell has written a public domain display \PS\ for the Sun workstation which was shown at the meeting. This facility goes a long way to resolving one of the persistent problems with \PS\ --- the lack of screen preview. I find development work with \PS\ a nightmare. An aside: how is it that \PS\ is wonderful, and has been embraced by all my user-% friendly {\it wysiwyg\/} chums, despite its obvious unfriendliness, while \TeX\ remains an anathema to them: could it be something to do with marketing? Goswell's talk was extremely competent, and neutral. Fortunately here was someone who knew enough about \PS\ to know its strong and weak points. One of the items he covered was the problem of device independence. In theory, sending your \PS\ file to a laser printer, then to a typesetter should only change the resolution --- the document should look the same, only better. Unfortunately, as we all (?) know, this is not always the case. Rules in particular can change their appearance; memory usage is different in different rips (i.e.~your pages may not print at all), and of course the fonts you think you have used may not be available. Most \PS\ users will also have encountered the `preamble' problem --- and will know that there are lots of different releases of the \PS\ software for printers, all with different bugs (Let's ignore the clone problem for now.) Looking at \PS\ as a programming language, he pointed out that it is a plain text language -- you can read it --- it is complete, and it really is a language, not data. As a programming language it offers extensibility: Goswell saw no reason why \PS\ could not offer non-linear font scaling (a charge often levied against it). But he also noted that the language did encourage hacking, that it could be hard to read, and was difficult to debug --- consequences of the dynamic binding of the language and the ability to redefine anything whenever you pleased. Portability was generally good, although there were problems with manufacturer-specific extensions (as usual), and with fonts. This was very useful, evenly balanced and informative talk which may have swept away some of the misunderstandings and misconceptions which surround \PS. There were three other talks, from Heather Brown, Wendy Hall, and J\"urgen Sch\"onhut, but none were \TeX-relevant. \smallskip \rightline{\sl Malcolm Clark}