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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
|
.help gterm Dec86 "Vector Graphics for the Sun Workstation"
.sp 2
.ce
\fBVector Graphics for IRAF on the Sun Workstation\fR
.ce
Doug Tody
.ce
December, 1986
.ce
(design document)
.sp 3
.NH
Graphics Terminal Model
The window based, native vector graphics facility for Sun/IRAF will be
implemented as a purely data driven interface based on the concept of an
intelligent virtual graphics terminal. The virtual graphics terminal will
be implemented in software as a process running under a window system such
as Sunview or X.
A virtual terminal interface will allow the Sun workstation to be used as an
ordinary graphics terminal to access IRAF or other software on either the
local or a foreign host via any data stream interface, e.g., rlogin, telnet,
or a modem connection. For example, one will be able to use telnet running
in a GTERM window to login on a VMS machine, then run IRAF on the VMS machine
in the normal fashion. Conversely, since the IRAF software on the Sun node
will always think that it is talking to a conventional data driven graphics
terminal, the Sun/IRAF software may in fact be run from a conventional
graphics terminal, via either a direct or remote login. Finally, a pure data
stream TTY interface where all details of the windowing system are isolated
into a server process makes it possible for a single version of IRAF to support
multiple window systems on the same host.
The graphics terminal to be implemented by GTERM shall consist of independent
text and graphics frames. These will be implemented as separate windows
(frames) under SunView, allowing them to be moved, resized, exposed, hidden,
open, closed, etc., independently of each other. Note however that since both
frames are connected to the controlling process via a single terminal i/o
connection, the controlling process (e.g., the CL) can only read from or
write to one frame at a time.
In normal use, the user will work for a time in the text frame, issuing
commands to run tasks which do not require interactive graphics facilities.
When a graphics program is run the graphics frame will be opened or exposed
and the plot drawn. If the graphics program is interactive, i.e., uses
cursor input, the cursor will be moved to the center of the window and the
crosshairs turned on to indicate that cursor input is required. A sequence
of keystroke or mouse button triggered cursor reads will follow, and
eventually graphics mode will be exited by transmission of the close
workstation sequence to GTERM by GIO running in the applications program.
When graphics mode is exited GTERM terminal i/o is redirected to the text
frame and the cursor is restored to its former position in the text frame,
automatically restoring interactive control to the text frame. The graphics
frame may or may not be closed or hidden, depending upon the GTERM defaults
set up by the user. If the graphics frame is to be closed or hidden this
should probably require interactive confirmation by the user, else the plot
might disappear immediately after being drawn. Since control naturally
toggles back and forth between the text and graphics frames and since screen
space is always limited and a large, high resolution graph is generally
desired, it is expected that the graphics frame will normally be displayed
only while in graphics mode.
.NH
GTERM Graphics Language
The tektronix graphics language is a simple and efficient standard language
for graphics terminal i/o which will work about as well as anything in our
application. In particular, the vector encoding scheme is simple, compact and
efficient, and well suited to use with a variety of terminal drivers and
modems (since binary data is avoided). The best approach to implementing the
GTERM graphics language would seem to be to take the tektronix language as a
starting point and add additional functionality by extending the language
with new control sequences. Some of the extensions defined here a taken from
the Retrographics vt640 and the Pericom. Others more specific to window based
applications will be added in the future in an upwards compatible fashion.
.ks
.nf
GS open workstation if not already open
open/expose graphics frame (icon -> full window)
direct terminal i/o to graphics frame
save cursor (mouse) position
issue GS dark vector command (see below)
CAN close workstation
restore control to text frame (restore cursor)
close/hide graphics frame (full window -> icon)
keystroke required to trigger close-window?
GS (workstation already opened)
enter vector drawing mode, dark vector
FS enter point plot mode
US,CR enter alpha mode
text is drawn in graphics frame
defaults to transparent text, erase permitted
ESC CR enter text mode
lines of text are drawn on status line in
nontransparent (overwrite) mode
ESC SUB enter crosshair mode
ESC FF clear screen, initialize drawing modes
ESC/f [x,y] set crosshair position
GS [x,y] US sets alpha cursor position
ESC[0123] set character size (normal,2x,3x,4x)
ESC[`abcd] set line drawing style (normal,dotted,dotdash,sd,ld)
ESC/[012]d set drawing mode (set, clear, toggle)
ESC/[0123]w set polyline linewidth (normal,2x,3x,4x)
Standard screen resolution is 1024 by 780.
In graphics mode, chars are interpreted as [x,y] coordinate pairs.
In alpha mode, chars are interpreted as characters to be drawn.
.fi
.ke
A number of extensions to this basic language are being considered for future
implementation. Support for color, multiple text fonts, general polymarkers,
area fill, and possibly cell array are contemplated, as well as simple
extensions for window control and pop-down menus. Support for the standard
textronix features which have been omitted (vector point elimination,
incremental point mode, status enquiry) is possible. The interface is easily
extensible hence there is no need to attempt to define or support such features
in the initial interface.
.NH
Implementation Notes
The GTERM virtual terminal consists of two independent frames, the text
frame and the graphics frame. Selection of the frame to which output is to
be delivered is done at the lowest possible level, i.e., when the read system
call is issued by the terminal to accept terminal output from the pty
(pseudo-terminal driver) stream for the terminal. This is done by linking in
a custom version of the notify_read() primitive, the low level read primitive
for notifer based programs. Output is initially to the text frame. Output
is redirected to the graphics frame when GS is seen in the output stream,
and later restored to the text frame when CAN is seen. Input is controlled
independently by the two frames at a high level, hence does not have to be
switched.
All terminal operations are event driven. Graphics data is deposited into a
circular input buffer by an event driven read routine, which can issue
<ctrl/s>/<ctrl/q> to the terminal driver to control the rate at which input
is accumulated. A separate drawing routine running off an interval timer
is used to process data appearing in the input buffer. The drawing code is
always in one of three modes: vector drawing mode, alpha mode (randomly
addressable character drawing), or text mode (textual output to the status
line).
.SH
Appendix: Tektronix Graphics Language (Retrographics vt640)
.ks
.nf
*GS enter graphics mode; dark vector
*FS enter point plot mode
RS enter incremental point mode
*US,CR enter alpha mode, graphics plane, tek font
CAN disable graphics mode, restore output to terminal plane
ESC"0g alias for enter transparent mode
ESC"4g alias for enter crosshair mode
ESC"5g enter light pen mode
*ESC SUB enter crosshair mode
*ESC FF clear screen, initialize drawing modes
*ESC ENQ return cursor position, other status
ESC[0123] set character size (normal,2x,3x,4x)
ESC[`abcd] set line drawing style (normal,dotted,dotdash,sd,ld)
ESC/[012]d set drawing mode (set, clear, toggle)
ESC/f set crosshair position
*GS [x,y] US sets alpha cursor position
Vector coordinate encoding (max 10 bits = 1024 points res.):
high y P01XXXXX
low y P11XXXXX
high x P01XXXXX
low x P10XXXXX
Cursor return structure:
key PXXXXXXX
high x P01XXXXX
low x P01XXXXX
high y P01XXXXX
low y P01XXXXX
trailer <cr>
Standard 4010/4012 screen resolution is 1024 by 780.
In graphics mode, chars are interpreted as [x,y] coordinate pairs.
In alpha mode, chars are interpreted as characters to be drawn.
.fi
.ke
|
