summaryrefslogtreecommitdiff
path: root/info/digests/texline/no8/bcs.display
blob: 53ae1fef8c2579254a4ab7214570e413edaed748 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
\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}