@(#)devices.doc 10.1 (OAA-ASTRONET) 8/7/95 19:23:12
HEADER : devices.doc - Vers 3.6.003 - Aug 1994
A G L 3.6
DEVICES AND DRIVER RELATED DOCUMENTATION
Luca Fini
Francesco Tribioli
Revised: August 1994
This document gathers togeter all the implementation notes
related to devices and device drivers shipped with AGL Vers. 3.61
distribution kit.
AGL 3.61
Distribution notice
===================
The Astronet Graphic library has been designed and
implemented under the coordination of the Astronet Working Group
"Graphics and Image Displays".
The software is officially supported by Astronet and is
distributed by:
Astronet Documentation Facility (ADOC)
Osservatorio Astronomico di Trieste
C.P. Succ. TS 5
Via G.B.Tiepolo, 11
34131 Trieste, Italia
Tel: +39 40 319911
Fax: +39 40 309418
e-mail: adoc@astrts.astro.it
The distribution release may also be obtained by anonymous ftp
at:
sisifo.arcetri.astro.it:pub/agl
or via e-mail, from the author:
Luca Fini
Osservatorio Astrofisico di Arcetri
L.go E. Fermi 5,
50125 Firenze, Italia
Tel: +39 55 27521
Fax: +39 55 220039
e-mail: lfini@astrfi.astro.it
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 1
HEADER : epson.doc - Vers. 3.5.001 - L. Fini, Dec 1989
AGL Support for
EPSON FX-80 DOT MATRIX PRINTER
Luca Fini
Revised February, 1990
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 2
This document contains details and implementation notes
related to AGL support for the Epson FX-80 dot matrix printer or
Epson emulating devices.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 3
A rasterizing program suitable for the low-cost printer
Epson FX-80 or any suitable emulating device is included in the
AGL kit.
The program epson is a standalone program which converts a
file generated by the generalized raster driver provided by AGL
into commands for the printer. Details about the AGL raster
driver can be found in the related chapter of this document.
As specified in the example below the intermediate file
generated by the AGL raster device driver must be sorted by means
of any system provided sort utility before it can be used as
input to the epson program.
To get information on how to use the program simply run it
with the following command:
epson ?
The rasterizer may be also run automatically at device close
if a command like the following is included into the file
agldevs.dat:
eps:raster::=sort % | epson | lpr # Unix example
eps:raster::=sort % | epson -p # MS-DOS example
eps:raster::=epson % # VMS example
Under VMS a procedure .com which applies sort and epson
programs to intermediate files and then sends the result to the
printer is supposed. The foreign command EPSON which executes the
procedure is supposed to be defined.
More elaborate procedures may be devised, e.g. to delete
intermediate files, etc.
Source code for the program is in the file epson.c which is
automatically included into the building procedure for MS-DOS
target.
NOTE: The program is not automatically built and installed on
systems other than MS-DOS, but it can be compiled and linked very
easily on other Operating Systems if needed.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 4
HEADER : gpxvms.doc - Vers. 3.4.001 - F. Tribioli, Mar. 1989
AGL Support for
VAX/VMS WINDOWING WORKSTATIONS
Francesco Tribioli
March 1989
This document contains details and implementation notes
related to the use of standard AGL drivers on the VAX workstation
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 5
family.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 6
INTRODUCTION
VAX/VMS Workstation software provides a lot of specific
system function calls devolved to windows and graphics manage-
ment. However we preferred not to write an AGL server from
scratch because it is possible to create a complete Tektronix
4014 terminal emulator with a single system function call.
So the simpler way to allow the use of AGL on the work-
station screen is to create a Tektronix compatible virtual
terminal on the workstation and allocate it for future use.
The program GPXSERV.EXE is provided within the AGL Kit in
order to create such a window for subsequent use. Several
indipendent windows may be created with names: TKAn: with 'n'
an indentity number.
HOW TO CREATE A NEW AGL WINDOW
To create a graphic AGL window on a Vax/VMS Workstation
simply run GPXSERV. GPXSERV will create a Tektronix 4014
compatible terminal and will allocate it to the user. GPXSERV
will write on the principal window the name of the terminal that
it has allocated, this name being TKAn:, as we have seen
previously.
NOTE: The new window will not been displayed on the screen
until some kind of data will be written on it, but it
is alive as you can see performing a scan of all
present devices.
The window will be displayed on the screen just after the
first character written on the graphic device. The new window is
like any other workstation window and can be treated using menu
options. All options, excepted 'Delete', are working so you can
resize, move around and shrink to an icon your window.
HOW TO USE THE WINDOW WITH AGL
As usual within AGL you must both inform the application
program on the name of the physical device and provide informa-
tion on the type of the device.
The name of the physical device is obviously TKAn:, but any
logical name which translates into TKAn: may also be used.
E.g. in order to run the testing program IP and get output
on the Tektronix window you may type (see the Installation manual
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 7
to get specific information on testing procedures):
$ IP TKA1: <testfile>
The device type will be specified either in the AGLDEVS.DAT
file or in the AGL3DEV logical name. The most effective way is to
add the following three lines to the file AGL3CONFIG:AGLDEVS.DAT:
tka1:tkg.t4010
tka2:tkg.t4010
tka3:tkg.t4010
This will be valid for any window and will not conflict with
other device names.
GRAPHIC CURSOR
When the graphic cursor (locator) is enabled with the re-
lated AGL call (AG_VLOC()) the graphic window will not be at-
tached to the keyboard, and every character typed will go to the
text window. In this case the mouse buttons only will be sensed
by the software.
To get keyboard events when using the cursor is necessary to
click with pointer on the 'KB' symbol on the right of the title
bar of the AGL window: this action will attach the keyboard to
the graphic window.
REMOVING THE AGL WINDOW FROM THE SCREEN
Once you have terminated your graphic operations on a parti-
cular graphic window, you can remove it and the associated device
with the DCL command:
$ DEALLOCATE TKAn:
where 'n' is the number of that particular window.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 8
HEADER : hpgl.doc - Vers. 3.2.001 - L. Fini, Oct. 1988
AGL Support for
HPGL PLOTTERS
L. Fini
July 1988
This document contains details and implementation notes
related to the AGL driver for plotters using the HPGL graphic
language.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 9
INTRODUCTION
The AGL standard driver for plotters and other devices which
accept command in HPGL language has been designed in order to
allow to produce output on two different paper sizes (A4 and A3)
and two different paper orientations (Portrait and Landscape).
When using this kind of devices the actual output from
graphic applications is stored into files named: hpglplot.0,
hpglplot.1, etc. These files can be sent to the device via the
suitable locally defined operating system command, possibly
issued automatically by the standard AGL mechanism (See: "AGL
Installation and Customization Guide").
OUTPUT FORMAT SELECTION
Four different output formats are currently supported by the
AGL driver; they allow two paper sizes (A/A4 and B/A3) and two
output orientations (landscape, portrait).
The output format is selected at viewport open by appending
a format specification to the device identification string in the
AG_VDEF() call. Allowed format specifications are listed below:
Spec. Format
a A/A4 Landscape (default)
b A/A4 Portrait
c B/A3 Landscape
d B/A3 Portrait
In the following line an example of viewport definition call
is provided, which selects the A/A4 Portrait mode:
ivw=AG_VDEF("hpg.b:",.....);
In the example above it is assumed that "hpg" is the system
dependent name selected by the system manager to specify the
HPGL device.
KNOWN LIMITATIONS
No more than a single device using the HPGL driver can be
concurrently accessed by any process.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 10
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 11
HEADER : ibmpcscr.doc - Vers. 3.4.001 - L. Fini, Feb 1989
AGL Support for
IBM-PC (AND CLONES) SCREEN
L. Fini
February 1989
This document contains details and implementation notes
related to the AGL driver for the IBM-PC screen and other clones.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 12
INTRODUCTION
The AGL driver for the IBM-PC screen has been designed to be
used with various graphic cards. The graphic card information is
provided at run-time by means of a standard AGL device
identification mechanism so that any AGL based executable program
will work on any supported graphic card without need of
recompilation.
The following general points must be carefully considered:
- Running any program which accesses the PC screen will set
the graphic mode. In order to avoid screen erasing at the
end of the program execution, the driver will not reset the
graphic screen to alphanumeric mode. This must be accompli-
shed by the suitable DOS command (MODE). See the DOS manual
for details on how to reset the alphanumeric mode of the
screen. E.g.: the mode command suitable for the EGA color
card is:
mode co80
NOTE: the execution of this command may be automatic if the
command itself is included into the file AGLDEVS.DAT as
specified in the "Installation and Customization Guide"
(file: AGLINSTA.DOC). E.g.: if the device name selected for
the PC screen is con: the following line within AGLDEVS.DAT
will issue the screen reset command when the device is
closed:
con:ibmpc.ega::=mode co80
- The set of graphic mode is made by the 'ERASE' operation of
the driver. If only the device name for the screen is used
in the AG_VDEF call (see the reference manual for details of
AG_VDEF) the screen will be automatically erased at initia-
lization and the graphic mode will be set. On subsequent
runs of graphic programs, if erasing of previous plots must
be avoided, the /n modifier must be included into the device
specification so that the screen is not erased. Note that
the /n modifier cannot be used if the screen is still in
alphanumeric mode (i.e. the first time a graphic program is
executed) because of the above considerations.
GRAPHIC CARD SELECTION
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 13
The selection of the graphic card will be made by the
definition included in the AGLDEVS.DAT file on the AGL standard
directory (see the "AGL Installation and Customization Guide" for
details on the AGLDEVS.DAT file).
As example, supposing that you are working on a plain IBM PC
with CGA you may include into AGLDEVS.DAT the following line:
con:ibmpc.cga
And refer to the screen with the device name con:.
If the name of the graphic card is not recognized by the
driver (see table below for supported cards) it will return with
a DEVOPNERR code.
CURRENTLY SUPPORTED GRAPHIC CARDS
The following graphic cards are currently supported (but see
into the file ibmpcdrv.c for possible updates):
cga Standard IBM CGA
egc Olivetti M-24 (AT&T 6300) EGC
egam Monochromatic EGA
egac 16 Colors EGA
INTERACTIVE CURSOR
The software generated cursor appears as a cross on the
screen when enabled and can be moved by means of the arrow keys
of the keyboard. Moving speed can be increased (decreased) by
pressing function key F1 (F2).
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 14
HEADER : nulldrv.doc - Vers. 3.6.001 - L. Fini, Sep 1993
AGL Support for
NULL DEVICE
L. Fini
October 1993
This document contains details and implementation notes
related to the AGL driver for the "null" device, i.e. a device
which can be use to sink graphic commands.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 15
INTRODUCTION
The AGL null device is a dummy device which sinks every
graphic command it receives.
It can be use when the graphic output is not necessary for
a given run of an application, or to generate a metaafile without
the corresponding graphic output.
FORMAT SELECTION
Although the null device doesn't produce any output, it has
a device aspect ratio whose definition is necessary for the calling
application to work properly.
The null device has a default aspect ratio which is the same
as an A4 sheet in landscape mode (approx. 0.69), but this may be
changed to suit application needs by means of either the "user" or
the "system" device specification string allowed in the AGL device
names.
Here is an example of an AG_VDEF call which specify the
an aspect ratio equal to 1 (square):
ivw = AG_VDEF("nl.1000:",......);
the aspect ratio specification is an integer number equal to
the required aspect ratios times 1000.
A call as follows:
ivw = AG_VDEF("nl.1000:",......);
will select the default aspect ratio.
In the example above it is assumed that the name "nl" has
been defined by the system manager as the one to select the
null device.
DEVICE TYPE DECLARATION
The declaration of the device type is performed by adding a
suitable specification in the device definition file
"agldevs.dat" (See also "AGL Installation and Customization
manual"). Here follows an example of such a declaration (the
following line are included into the file "agldevs.dat"):
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 16
nl:null # Null device, default aspect ratio
nl1:null.1000 # Null device, aspect ratio = 1
nl2:null.1447 # Null device, aspect ratio == A4 portrait
NOTE: The aspect ratio of the null device can also be specified
in the device configuration file as shown above. In this case the
user specified aspect ratio will supersede the value set in the
file.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 17
INCLUDING AGL GENERATED POSTSCRIPT FILES INTO TEX DOCUMENTS
Some TeX implementations allow the inclusion into a document
of graphs and pictures coded as PostScript programs by using a
format known as "Encapsulated Postscript".
AGL generated plots are as compatible as possible with
Encapsulated PostScript and can be included into TeX documents
provided the following directions are followed.
1) Use portrait mode. That's the mode usually set for TeX pages
and mixing of portrait and landscape on a single page is
apparently harmful.
2) Do not use AG_VERS (erase) call. If you erase a portion of a
plot the result is not logical (if you don't want a portion of
a plot to appear, simply don't draw it!); if you erase the
entire page, then AGL will eject current page and start a new
one, but this is not a correct instruction for a plot you want
inclkude into a document. If you happen to have an existing
application which generates multiple page plots you may still
include one of the pages into a document if you edit the Post-
Script file and strip off the unwanted page(s). To ease this
job AGL generated files have an "END OF PAGE" comment at the
end of each page.
With reference to the AGL PostScript file format as shown in
the following lines, in order to include a page of a multi-
page plot it is necessary to include: the header (i.e. the lines
above the "BEGININNING OF PLOT" comment) and the required page
(copypage command not included).
STRUCTURE OF AN AGL POSTSCRIPT FILE
.... HEADER ....
% BEGIN OF PLOT
.... }
.... PostScript commands .... } Page 1
.... }
copypage % END OF PAGE
.... }
.... PostScript commands .... } Page 2
.... }
copypage % END OF PAGE
.... }
.... PostScript commands .... } Page 3
.... }
copypage % END OF PAGE
....
....
....
....
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 18
....
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 19
HEADER : pscript.doc - Vers. 3.6.010 - L. Fini, Jul. 1994
AGL Support for
POSTSCRIPT PRINTERS
L. Fini
October 1993
Revised
July 1993
This document contains details and implementation notes
related to the AGL driver for printers using the PostScript page
description language.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 20
INTRODUCTION
The AGL standard driver for plotters and other devices which
use the PostScript language will generate a file containing
PostScript sequences which can be sent to a PostScript device.
The current version of the PostScript driver will allow both
landscape (default) and portrait output modes with A4 and A3
paper size, and supports colour printers.
When using this kind of devices the actual output from
graphic applications is stored into files named: pscrplot.0,
pscrplot.1, etc. These files can be sent to the device via the
suitable locally defined operating system command, possibly
issued automatically by the standard AGL mechanism (See: "AGL
Installation and Customization Guide").
OUTPUT FORMAT SELECTION
The selection of the output format is performed by appending
specifications to the device name as specified at viewport defi-
nition (see also the AGL Reference Manual, routine AG_VDEF).
Allowed format specification characters are as follows (they can
be specified in any order):
Spec. Format
l Landscape (default)
p Portrait
3 A3 size
4 A4 size
u US-legal size
Here are some examples of AG_VDEF calls:
ivw = AG_VDEF("ps.p3",......); Portrait A3
ivw = AG_VDEF("ps.l3",......); Landscape (default) A3
ivw = AG_VDEF("ps.4p",......); Portrait A4
ivw = AG_VDEF("ps.l",......); Landscape A4 (default)
ivw = AG_VDEF("ps.up",......); Portrait US-legal
As usual the device specification string may be an
environment variable name which translates into the required
string.
In the example above it is assumed that the name "ps" has
been defined by the system manager as the one to select the
PostScript device.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 21
DEVICE TYPE DECLARATION
The declaration of the device type is performed by adding a
suitable specification in the device definition file
"agldevs.dat" (See also "AGL Installation and Customization
manual"). Here follows an example of such a declaration (the
following line are included into the file "agldevs.dat"):
ps0:pscript::=lpr -Plp0 % # printer name is lp0
Output PostScript commands will be suitable for colour printers.
B/W only printers will use grayshade for different colors.
KNOWN LIMITATIONS
No more than a single device using the PostScript driver can
be concurrently accessed by any process.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 22
INCLUDING AGL GENERATED POSTSCRIPT FILES INTO TEX DOCUMENTS
Some TeX implementations allow the inclusion into a document
of graphs and pictures coded as PostScript programs by using a
format known as "Encapsulated Postscript".
AGL generated plots are as compatible as possible with
Encapsulated PostScript and can be included into TeX documents
provided the following directions are followed.
1) Use portrait mode. That's the mode usually set for TeX pages
and mixing of portrait and landscape on a single page is
apparently harmful.
2) Do not use AG_VERS (erase) call. If you erase a portion of a
plot the result is not logical (if you don't want a portion of
a plot to appear, simply don't draw it!); if you erase the
entire page, then AGL will eject current page and start a new
one, but this is not a correct instruction for a plot you want
inclkude into a document. If you happen to have an existing
application which generates multiple page plots you may still
include one of the pages into a document if you edit the Post-
Script file and strip off the unwanted page(s). To ease this
job AGL generated files have an "END OF PAGE" comment at the
end of each page.
With reference to the AGL PostScript file format as shown in
the following lines, in order to include a page of a multi-
page plot it is necessary to include: the header (i.e. the lines
above the "BEGININNING OF PLOT" comment) and the required page
(copypage command not included).
STRUCTURE OF AN AGL POSTSCRIPT FILE
.... HEADER ....
% BEGIN OF PLOT
.... }
.... PostScript commands .... } Page 1
.... }
copypage % END OF PAGE
.... }
.... PostScript commands .... } Page 2
.... }
copypage % END OF PAGE
.... }
.... PostScript commands .... } Page 3
.... }
copypage % END OF PAGE
....
....
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 23
....
....
....
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 24
HEADER : raster.doc - Vers. 3.5.001 - L. Fini, Feb 1990
AGL Support for
RASTERIZING DEVICES
Luca Fini
January 1989
Revised: February 1990
This document contains details and implementation notes
related to the AGL generalized driver for rasterizing device.
This driver will not produce output for actual devices. It will
generate a standard file suitable to be converted into raster
output by device specific programs.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 25
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 26
INTRODUCTION
The generalized AGL driver for rasterizing devices is not
suitable by itself to control specific raster device. It gene-
rates a standard file containing information suitable to be
converted into raster output by device specific programs. The
output generated by the driver can thus be used to control
different kind of devices.
NOTE: See appendix for specification of available rasterizing
programs.
The driver can manage different paper sizes and orientations
(Portrait and Landscape).
Actual output is sent to a file named vector.* (where * is a
number) and must be processed through a rasterizing program
suited to the specific device which must be used. The processing
and printing procedure can be issued automatically by means of
the standard AGL mechanism for issuing commands at device close.
OUTPUT FORMAT SELECTION
The output format is affected by:
- Dimensions required when the viewport is opened by
means of the related arguments in the call. E.g.: to
require a 12.5 x 50 cm viewport you may use the call:
ivw=AG_VDEF("rs:",x0,x1,y0,y1,12.5,50);
It will result into a 12.5 cm X-axis and a 50 cm Y-axis
box, because the output orientation is "Landscape" by
default (see below).
- Paper orientation selected with the device name speci-
fication when the viewport is opened (default is Land-
scape). E.g.: to select portrait mode for the device
"rs:" you may use the call:
ivw=AG_VDEF("rs.p:",.....);
- Dimension of the strips into which the output is sub-
divided, selected by the system manager into the AGL
configuration file agldevs.dat. This value (defaulted
to 10 cm) must be selected as a tradeoff between speed
and output file dimension and memory space required by
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 27
the rasterizing program, which increases for longer
strips.
This parameter may be adjusted on a per device basis by
the system manager changing the value into the line
related to the device in the configuration file agl-
devs.dat. E.g.: in the following example we select a
strip length of 250 mm for the device rs:
rs:raster.250 # This is a line into agldevs.dat
KNOWN LIMITATIONS
No more than a single device using the raster driver can be
concurrently accessed by any process.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 28
WRITING RASTERIZERS
The following sections contain information useful to pro-
grammers who want to write rasterizing programs for specific
devices.
VECTOR FILE ORGANIZATION
The coordinate values written onto the output file are
subdivided into a number "strips" of given width (equal to the
requested paper width) and length (see above for directions on
strip length selection) to reach the requested total length of
the plot.
Each segment to be drawn by the rasterizer is guaranteed to
lie within one of the strips, so that the rasterizing program can
operate on a single strip at a time. Longer segments are thus
subdivided into shorter one in order to comply with the above
property.
In order to allow the rasterizer to access the vector file
sequentially, the lines of the file must be sorted in ascending
alphabetic order by any sorting utility. The format of the file
has been designed so that any sort utility will properly sort the
file (the sort can, moreover, be based on the first character
only of each line of the file).
VECTOR FILE FORMAT
The vector file generated by the raster driver is an ascii
file which contains vector information for segment to be drawn.
The first line of the file has a special meaning and has the
following format:
<blank>paper_width paper_length strip_length
where:
<blank> is a single leading blank character (ascii 32)
paper_width is the requested paper width
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 29
paper_length is the requested paper length
strip_length is the length of a single strip
The blank at the beginning of the line ensures that after the
sort this line will remain the first of the file.
All the remaining lines of the file have the following
format:
<char>wd0 ln0 wd1 ln1 width
where:
<char> is a single ascii character which encodes the
strip number. Only ascii codes in the range [33-
126] inclusive are used. Ascii code 33 ('!')
represents the first strip. The space code (32) is
reserved to flag the first line.
wd0 are the coordinates of the segment starting point
ln0 (wd is along paper width, ln along paper motion)
wd1 are the coordinates of the segment ending point
ln1 (wd is along paper width, ln along paper motion)
width is a single digit decimal number for line width.
All numbers representing dimensions or coordinate values in
the files are floating point values in millimeters with two
decimal digit (the resolution is thus 1/100 of a millimeter).
Coordinates are referred to the plot origin, i.e. to the upper
left point of the drawing area.
The driver also guarantees that ln0 <= ln1.
Here is an example of file generated by the raster driver:
180.000000 120.000000 20.000000
! 180.01 0.00 150.00 20.00 0
" 150.00 20.00 120.00 40.00 0
# 120.00 40.00 90.00 60.00 0
$ 90.00 60.00 60.00 80.00 0
% 60.00 80.00 30.00 100.00 0
& 30.00 100.00 -0.00 120.00 0
' -0.00 120.00 0.00 120.01 0
! 0.00 0.00 30.00 20.00 0
" 30.00 20.00 60.00 40.00 0
# 60.00 40.00 90.00 60.00 0
$ 90.00 60.00 120.00 80.00 0
% 120.00 80.00 150.00 100.00 0
& 150.00 100.00 180.01 120.00 0
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 30
' 180.01 120.00 180.01 120.01 0
and here follows the same file after sorting:
180.000000 120.000000 20.000000
! 0.00 0.00 30.00 20.00 0
! 180.01 0.00 150.00 20.00 0
" 150.00 20.00 120.00 40.00 0
" 30.00 20.00 60.00 40.00 0
# 120.00 40.00 90.00 60.00 0
# 60.00 40.00 90.00 60.00 0
$ 90.00 60.00 120.00 80.00 0
$ 90.00 60.00 60.00 80.00 0
% 120.00 80.00 150.00 100.00 0
% 60.00 80.00 30.00 100.00 0
& 150.00 100.00 180.01 120.00 0
& 30.00 100.00 -0.00 120.00 0
' -0.00 120.00 0.00 120.01 0
' 180.01 120.00 180.01 120.01 0
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 31
A P P E N D I X
AVAILABLE RASTERIZERS
1. Epson FX-80 Printer Rasterizer
2. Versatec Printer Plotter
(See specific documentation on the rasterizing programs in the
related chapters of this document)
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 32
HEADER : teklike.doc - Vers. 3.6.000 - L. Fini, Jan 1991
AGL Support for
TEKTRONIX (AND ALIKE) DEVICES
L. Fini
September 1989
Revised: January 1992
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 33
This document contains details and implementation notes
related to the AGL driver for Tektronix and Tektronix emulating
devices.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 34
INTRODUCTION
The AGL standard driver for Tektronix devices has been
designed to be driven by "capabilities files" which take into
account the small differences in control sequences, so the
support of any such device should be simply accomplished by
writing the few lines of the required cap file.
The current version of the driver supports Tektronix termi-
nals of the 40xx and 41xx families, and other Tektronix emulating
devices.
As a general advice the following points must be taken into
account:
- Uneven pixel mapping. Tektronix emulators have usually lower
resolution than the 4010. When in emulation mode there is no
way to get a one to one mapping between physical coordinates
and pixels. This usually makes it difficult the generation
of software characters and symbols, or better, software
generated characters and symbols appear considerably lop-
sided and often aesthetically bad. This is, anyway, a
strictly hardware dependent limitation and cannot be avoided
(unless by buying a full resolution terminal).
- The standard Tektronix 4010 terminal, may cause problems if
alphanumeric I/O and graphic operations are interleaved, in
that, while AGL maintains the current cursor position and
restores it before the dumping of the graphic buffer, usual
terminal I/O assumes that the alphanumeric cursor position
is independent from the graphic cursor position, which is
not true for the 4010. This problem is not negligible in
that most PC-based Tektronix emulators are, in this respect,
quite close to the real thing. The only effective solution
is to program application so that graphic and alphanumeric
I/O is completely separated.
- When using Tektronix emulation on Laser printer you may not
expect better resolution than the standard 1024x780 screen.
This is in fact not a limitation of AGL, but an ovious
feature of the emulation.
CAPABILITIES FILES
In order to cope with small differences in the control
sequences which are typical of tektronix emulating devices the
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 35
AGL driver reads a device specific file when the device is
opened. This file must contain a set of control sequences
suitable to control the device.
Control sequences are ASCII codes (control and printable)
expressed as decimal numbers separated by spaces and or newlines
and terminated by the value 0. This means that a single sequence
can be subdivided into more than one line.
The format of the cap file can be derived from the following
examples:
# plain tektronix 4010 cap file
tt # The device is a terminal
18 12 # Screen dimensions
0 # Initialization string (none required)
29 0 # set the graphic mode
31 0 # Reset alpha mode
29 27 26 0 # Enable cursor
29 27 12 31 0 # Erase screen
0 # Termination string (none required)
# QMS laser printer in Tektronix emulation mode
QMSPLOT # Output to the file QMSPLOT.n
26.0 19.8 # Paper sheet dimensions
94 80 89 94 95 10 94 # Initialization sequence (long sequences may be
73 71 84 94 95 10 94 # Subdivided into more than a single line)
80 78 94 95 10 0 # End of initialization sequence
22 29 0 # Set the graphic mode
27 10 0 # Reset alpha mode
0 # Enable cursor (unsupported)
27 12 0 # Erase screen (newpage)
94 80 89 94 95 10 94 # Termination sequence
73 71 69 94 95 10 94
80 78 94 95 10 0 # End of termination sequence
# Tektronix 41xx color terminal
tt # Output to terminal
18 12 0 16 # Screen dim.,(unused), # of colors
27 37 33 48 0 # Initialization sequence
29 0 # Set graphic mode
31 0 # Reset alpha mode
29 27 26 0 # Enable cursor
29 27 12 31 0 # Erase screen
27 37 33 49 0 # Termination sequence (reset ansi mode)
27 77 76 0 # Escape sequence to change color
The meaning of the eight lines is as follows:
1. tt on the first line indicates that the device is a ter-
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 36
minal. Any other name will be interpreted as a file name and
the output will be stored into it. In the example for the
QMS printer the name qmsplot means that the output will be
put into files named: qmsplot.0, qmsplot.1, etc.
2. Two floating points values, (X and Y screen dimensions in
cm). The two values may be followed by two more integers.
The first is a dummy value (for compatibility with older
versions of the files, and the second, if present, is the
number of colors. If these integer values are found on this
line the device is assumed to be a 41xx type and a 9th line
must be added at the end of the file with the sequence for
color selection.
3. Device initialization. This is the sequence needed to pre-
pare the device to perform Tektronix emulation. It is a null
string for the real Tektronix 4010, while it is a
complicated sequence for the QMS laser printer.
4. Set graphic mode. The device will usually stay in
alphanumeric mode, and will be set in graphic mode any time
a buffer of command is sent to it. This sequence is the
command needed to pass from the alphanumeric mode to the
graphic one.
5. Reset alphanumeric mode. This is the sequence needed to
reset the alphanumeric mode. Many emulators provide a
'VT100' alphanumeric mode which is different to the
'Tektronix' alpha mode. The sequence will usually reset to
the former.
6. Enable the cursor. This is the sequence needed to enable the
screen crosshair cursor and wait for key depression. The
laser printer has not a cursor so that the related sequence
is null.
7. Erase screen. This is the sequence needed to erase the
screen. It may have various meanings if the device is not a
screen, but a printer or plotter; e.g. the QMS laser printer
will eject the current page.
8. Termination. This is the sequence needed to orderly reset
the device in the original status. It is a null string for
the real Tektronix 4010 and a complicated sequence to reset
the QMS printer to the usual mode of functioning.
9. Set color. This line is required for terminals of the 41xx
family (the two optional integer values must be present on
line 2 of the cap file), and it must contain the command
sequence needed to change color.
INTERACTIVE CURSOR
The kind of cursor used for interaction is hardware
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 37
generated and may be different on different tektronix emulators.
You must check on the specific manual to find out how to control
its position.
DEVICE TYPE SELECTION
Tektronix like devices will be declared in the agldevs.dat
file with lines as shown in the example below:
tt:tkg.t4014
qms:tkg.qms::=laser %
where the first line refers to the standard output terminal which
is declared to be a Tektronix 4014, and the second to a device
named qms which is a QMS laser printer. Here the system command
laser filename
is supposed to be the locally defined command needed to dump a
file onto the laser printer (see also the AGL installation and
customization guide).
Any device type specification of the form:
tkg.xxxx
will refer to the tektronix driver and will require that a file
named xxxx.cap and containing the proper commands is readable on
the AGL standard directory.
Alternately, the default device type specification can be
stored in the environment variable AGL3DEV as specified in the
"AGL Installation and Customization Guide".
CURRENTLY AVAILABLE CAP FILES
The currently available cap files are listed in the
following table (but list all *.cap files on the AGL default
directory to check whether other caps file are available at your
site).
Device File name
QMS Laser Printer qms.cap
Human Design 2200 terminal hds22.cap
CIT 101(CIG card) cit101.cap
Tektronix 4010 t4010.cap
Retrographics VT640 vt640.cap
Tektronix 4014 t4014.cap
Tektronix 41xx t4100.cap
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 38
LN03 Laser Printer ln03.cap
LN03 Laser Printer (old) ln03x.cap
Note 1: Due to a difference in Tektronix 4010 and Tektronix
4014 use in older versions of the tek-driver two
capabilities files named t4010.cap and t4014.cap are
still distributed, but they are exactly equal. I.e.:
you may declare any Tek 4010 or 4014 terminal either as
tkg.t4010 or tkg.t4014.
Note 2: The file ln03.cap (capabilities file for the Digital's
LN03+ laser printer) has been revised as of version 3.6
of AGL on the basis of a bug report from a user. It has
not been tested directly, anyway, so that the old vers-
ion of the file is provided with the name: "ln03x.cap",
just in case that in some configurations the new one
should not work properly.
KNOWN LIMITATIONS
There are two possible sources of limitations in the
implementations of the Tektronix AGL driver.
The first is the number of different Tektronix-like devices
that can be concurrently opened. This is usually set to 2 (two),
in that it is unlikely that a user may need more than two such
devices concurrently open (e.g.: the current terminal and an
hard-copy device). To adjust this number you may edit the source
file tekdrv.c and modify the parameter NDEVS (you must also
modify accordingly the initializations of the two vectors:
channel and color).
The second one is the buffer space allocated to hold device
control sequences, usually set to 200. You may adjust this value
by modifying the parameter CMDBUFLNG in the source code.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 39
HEADER : versatec.doc - Vers. 3.5.001 - F. Tribioli, Dec 1989
AGL Support for
VERSATEC V80 PRINTER-PLOTTER
Francesco Tribioli
December 1989
This document contains details and implementation notes
related to AGL support for Versatec V80 plotters.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 40
INTRODUCTION
Versatec V80 is a raster printer using electrostatic tech-
nology to produce medium resolution graphic output on continuous
form. It is preferred sometimes to plotters because, it is possi-
ble with it to produce very complex plots in a shorter time. It
is also usable to produce gray level images in a quite short
time. Now it is somewhat substituted by laser printers, that
produce higher quality outputs. With Versatec however is possible
to have very long plots (say a meter or two, or even more),
which is not possible with any laser printer.
AGL support for Versatec rests on the general raster device
driver (documented in the related chapter of this document).
Three different programs are provided, which convert files pro-
duced by the raster device driver in a form suited to Versatec
printers. These programs have been tested on VAX/VMS only, but
they compile also on UNIX. If some body will try the UNIX ver-
sion, a brief report about bugs or problems will be welcome.
HOW TO USE VERSATEC SOFTWARE
The first thing to do is to sort the output from raster
device. This file has a name like VECTOR.n where n is a number
(i.e. VECTOR.0). Sort must be done with operating system provided
utilities. It is sufficient to sort on the first character of
each line. Then the sorted file can be passed to the Versatec
specific software.
AGL distribution comes with three programs: PLOTV80, VERSA-
TEC and SENDV80. The first one directly produces an output on a
Versatec printer from files produced by the AGL raster device
driver, and then sorted. The other two programs must be used
together: VERSATEC produces a bitmap in a compressed form; this
compressed bitmap will be used by SENDV80 to produce the plot.
ONE STEP PROCEDURE
PLOTV80 directly produce output on Versatec, so it is about
50% faster then the two step procedure, however it has a problem
due to the way bitmaps must be created.
The raster device driver, in order to produce plots of any
length without problems allocating memory, splits plots in
stripes of fixed length. In this way it is possible to get all
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 41
the plot reconstructing a stripe, sending it to printer, recon-
structing the next one and so on, and is needed memory only to
contain a single stripe.
This is very useful, but it causes a problem using Versatec
printers, because Versatec printers need a uniform feeding of
data. If for some reason there is a pause in the middle of a
plot, some dark lines compare where paper was stopped. Sending
plot directly to printer (as does PLOTV80) a pause is needed to
allow computer to reconstruct next stripe. The intensity of lines
is directly proportional to the length of pause. So a way to
reduce this effect is to select a smaller length for stripes
(this is selectable in AGLDEVS.DAT when raster device is defined,
see the chapter on the generalized AGL raster driver in this
document).
TWO STEP PROCEDURE
Another way to solve the problem is to produce the full
bitmap on a file and then send it to the printer. This is done by
VERSATEC that reconstructs the bitmap in a file. However because
of the great number of points per line (about two thousands) a
bitmap of about 6Mb is needed to produce a two meters length
plot. This is not very comfortable, and also slow down the pro-
gram due the large amount of IO needed. So a very simple compres-
sion algorithm has been implemented in VERSATEC. The compression
factor is of the order of a tenth (600kb for a typical two meter
long plot). Then SENDV80 reads this file, decompress it and sends
the bitmap to Versatec row by row, achieving a constant data
feed.
Using intermediate files is also useful if Versatec printer
is installed on a VAX/VMS, but user programs are running on a
UNIX machine. In this way one can produce the intermediate file
on his UNIX machine, transfer the intermediate file to a LAN con-
nected VAX and then use SENDV80 on VAX to get output.
CONTROLLING OUTPUT PARAMETERS
Both VERSATEC and PLOTV80 allow selection of some switches
for output control. Here they are:
-wf apply a scaling factor f along paper width
-lf apply a scaling factor f along paper length
-c select clipping mode when requested width is
larger than available (default is rescaling mode)
-s enable splitting of large plot in stripes when
requested width is larger than available.
Disable -c switch (default is rescaling mode)
-h -? Print help information on screen.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 42
After one or more switch selection it is possible to add one
file name for PLOTV80 or two file names for VERSATEC. The first
one file name for both programs must be a sorted version of the
file produced by general AGL raster device. This name is option-
al, default being standard input. The second name, only for
VERSATEC program, is the output file name. Also this name is
optional, default being standard output.
All the sequence of command can be put in AGLDEVS.DAT to be
run after viewport closing. For example a line that can be put in
AGLDEVS.DAT could be (UNIX systems):
rs:raster.250::sort % | plotv80
If you want to use the two step solution, it is better to
write a brief shell script, in UNIX environment, or command file,
in VAX/VMS environment, that accepts as parameter the name of the
output raster device file, and does the three steps needed:
sorting rasterizing and printing. For example in VMS environment:
$!Command file to print on Versatec Printer/Plotter
$ SORT 'P1' SORTED.TMP
$ VERSATEC -S SORTED.TMP RASTER.TMP
$ SENDV80 RASTER.TMP
$ DELETE SORTED.TMP
$ DELETE RASTER.TMP
and in UNIX environment:
#!/bin/sh
# Bourne shell script to print on Versatec Printer/Plotter
sort $1 > sorted.tmp
versatec -s sorted.tmp raster.tmp
sendv80 raster.tmp
rm -f raster.tmp sorted.tmp
So AGLDEVS.DAT line could be:
rs:raster.200::@plot %
on VAX/VMS or
rs:raster.200::source plot %
on UNIX.
CONFIGURING AND INSTALLING
Before compilation file VERSATEC.H should be edited to
control if parameters correspond to own printer. Parameter to
edit are printer device name, number of pixels per line, dimen-
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 43
sion of printer buffer (I think normally should correspond to
half a line dimension).
In UNIX environment it is necessary to control if file
vcmd.h exists. It contains definitions for ioctl commands. Detail
about these codes should be present in Versatec controller manu-
al. All installation dependent feature should be included in
versatec.h and vcmd.h files, however if something doesn't work
correctly, UNIX user can look at file sendv80.c which include all
system dependent calls for two step procedure.
On VAX/VMS the programs must be defined as foreign commands
in order to allow the command line arguments. For example:
$ SENDV80 :== $DISK:[DIRECTORY]SENDV80.EXE
The above commands can be included into SYSLOGIN.COM proce-
dure.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 44
HEADER : window.doc - Vers. 3.6.000 - L. Fini, Nov 1991
AGL Support for
UNIX WINDOWING WORKSTATIONS
L. Fini
February 1989
Revised: May 1991
This document contains details and implementation notes
related to the AGL driver for windowing workstation such as Sun 3
and Sun 4 family, the Apollo family, or the GPX/Ultrix family
devices.
NOTE
Here is a list of differences from modifications introduced as of
AGL version 3.53:
1. The SunWindows and X11 servers are now named differently:
they both used to be named "aglserv"; now the standard
building procedure will name them: "sunserv" and "x11serv",
respectively. You may obviously rename any of them if you
want to maintain the previous name.
2. The X11 server (but not the SunWindow server) now accepts
window geometry specifications in the standard X11 format
(see below for details) which differs from the previous way
to specify window size.
MAJOR ENHANCEMENTS IN VERSION 3.6
1. Speed has been improved optimizing the data exchange with
the server.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 45
2. The window is redrawn whenever it is exposed also when the
X11 server is used (formerly only the Sunwindow server pro-
vided this capability).
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 46
INTRODUCTION
The AGL standard driver for the windowing environment
(winddrv.c) has been designed to operate together with a
concurrent process which actually controls the graphic windows.
The two processes communicate via a FIFO exchanging messages
and commands. A single driver can control more than one window,
each selected by a unique name.
As a general advice the following points must be taken into
account:
- AGL is not responsible for window management: windows must
be created and destroyed at the O.S. level by means of the
given utilities (see sunserv, x11serv, killserv, below). As
a consequence the AGL library and the user programs built by
means of it have no dependency whatsoever from the window
system. Any program may send data onto any supported window
system. E.g. A program running on a Sun workstation may
operate either in conjunction with a SunWindows AGL window
or with an X11 window with no need of recompilation.
- An AGL window created by a server can usually be moved or
resized by means of usual mouse directed commands, provided
that such modifications are made BEFORE than the first
viewport is opened by the graphic application program.
- The AGL driver can hardly detect failures of the window
processes. Any failure due to external events (kill signals
and the like) are likely to hang up the application running
AGL.
WINDOW MANAGEMENT UTILITIES
AGL distribution kit contains two utilities which are
automatically generated at AGL installation. They must be used to
create and destroy windows to be used by AGL.
WINDOW SERVERS
Prior of performing graphic operations a window server
program must be activated. The server will create a window on the
screen and wait for graphic commands.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 47
Two different window server are currently supported:
sunserv: for Sun workstations running the native window
system (SunWindows).
x11serv: for Unix workstations with support for the MIT X-
11 window system.
After running the proper server a window is ready for graph-
ic I/O. The server process will usually be run in background,
e.g. with the C-shell command:
sunserv &
or
x11serv &
so it will be possible to activate any number of windows
spawning the server more than once: but they must have different
names to avoid interferences (see below for naming windows).
Both server accept a set of command modifiers as specified
below in the following pages.
SUNSERV
Usage: sunserv [-wwidth] [-hheight] [-H] [name] &
Where: width window width (No of pixels). If not specified
a suitable default is provided.
height window height (No of pixels). If not
specified a suitable default is provided.
name window name: The actual name will be obtained
by appending this string to the prefix
"AGL_". If no name is specified the string
"wnd" is assumed by default.
-H Print help message and exit. Other modifiers are
ignored.
Example: the following command will create a window 700x500
pixels wide, named AGL_mywind, and will return the O.S. prompt
after spawning the related process in the background.
sunserv -h500 -w700 mywind &
as a result of the command two FIFOs for communication with the
AGL based application, named AGL_mywind0 and AGL_mywind1, will be
created in the current directory .
X11SERV
Usage: x11serv [=geometry] [-H] [name] &
Where: geometry is a standard X11 geometry specification
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 48
of the form:
[<width>x<height>][{+-}<xpos>{+-}<ypos>]
[] enclose optional parts
<> enclose numeric values
{} enclose choice
name is the window name.
-H Prints an usage message and exits
Example:
x11serv =500x400+200+300 mywin &
Creates a 500x400 pixel window with upper left corner placed
200 pixels from the left border and 300 pixels down with respect
to top border named: AGL_mywin.
As a result of the command two FIFOs for communication with
the AGL based application, named AGL_mywin0 and AGL_mywin1, will
be created in the current directory .
BUILDING THE SERVERS
Suitable makefiles for the building of the server are pro-
vided with the AGL kit. The selection of the kind of server is
made by editing the makefile and commenting in and out clearly
stated lines. The makefile may be used to build both servers on
the same machine (e.g. X11 and SunWindows server on a Sun work-
station).
KILLSERV
The utility killserv can be used to destroy a previously
created window together with the associated FIFOs and process.
Note that the unix command kill can also be used to kill the
process, but the FIFOs will no be removed from the directory and
(depending on O.S. characteristics) the window might not be
deleted from the screen.
In order to function killserv must find the window FIFOs in
good shape, otherwise it will not be able to do its job. I.e.
killserv cannot be used to kill a window after some failure,
because the FIFOs will likely be in a garbled status. In this
case the unix kill command (and rm for FIFOs) can be used.
Killing a window when the graphic application is still
trying to send data to it can result into unpredictable results,
usually every process will hang up.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 49
Usage: killserv [-H] [name]
name window name: The actual name will be obtained
by appending this string to the prefix
"AGL_". If no name is specified the string
"wnd" is assumed by default.
-H Print help message and exit. Other modifiers are
ignored.
NOTE: the utility killserv is independent on the window system.
I.e.: the same program can be used to kill any kind of windows
supported on the target machine.
NOTE: Communication between the AGL server and the application
programs is performed via named pipes or FIFOs. The required
FIFOs are created on the current directory (i.e. the directory
from which the command starting the server is issued). If the
current directory is changed after running the server the appli-
cation program will not find the communication FIFOs and will not
be able to send/receive data to/from the server.
WINDOW SELECTION
In order to access a previously created window the AGL
application must specify the window name. This is accomplished by
the auxiliary information which can be appended to the device
identification in the AG_VDEF call (see: AGL Reference Manual).
Here are some examples of calls of the AG_VDEF routine from
user source code. Note: the logical name ws is supposed to be
defined into the agldevs.dat file with a line like the following:
ws:window
(see the "AGL Installation and Customization Guide" for further
details on agldevs.dat)
iv=AG_VDEF("ws:",......); Access the window with
standard name (AGL_wnd).
iv=AG_VDEF("ws.my:",...); Access the window named AGL_my
When running the AGL standard test programs the above
strings ("ws:" and "ws.my" can be typed at the device prompt to
get output on the related windows).
CURRENTLY AVAILABLE WINDOW SERVERS
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 50
Window servers have been tested on the following HW/SW
environments (but see also readme.doc for possible 'last minute'
updates):
Sun III/IV with native SunWindows environment
Sun III/IV with X11-window software
Apollo WS with X11 window software
NOTE: The X11 software has been designed in order to be
highly portable, so that the X11 support should be compilable on
any Unix system with X11 support.
LOCATOR USAGE DETAILS
On window workstations the locator device is usually
associated with the mouse. When the locator is activated via a
call to AG_VLOC a cross-hair or some other suitable cursor is
displayed on the screen. Then the cursor can be "catch" by the
mouse pointer (usually an arrow) and moved around. The cursor
position is then sent back to the application program when any
keyboard or mouse key is depressed. Keyboard keys will return
corresponding ASCII codes, whereas mouse buttons are usually
associated from left to right with the values 1, 2, 3,... (this
may be different on different window systems).
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 51
HEADER : x11.doc - Vers. 3.6.000 - L. Fini, Jan 1992
AGL Support for
X11 STANDALONE DRIVER
L. Fini
January 1992
This document contains details and implementation notes
related to the AGL standalone driver for X11 supporting worksta-
tions.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 52
INTRODUCTION
AGL supports X11 both through the standard "window" driver
together with the suitable X11 server program described elsewhere
(see section: "AGL support for Windowing workstations), and
through the standalone X11 driver.
Both drivers provide the same functionality with respect to
graphic output, but may be useful in different situations.
When using the AGL server, a graphic window is created by
means of a suitable O.S. command prior of the starting of the
graphic program(s) and remains active until killed with another
command (e.g: at the end of a session). This is useful when the
graphic application is subdivided into a set of programs and it
is required that the window lifetime is independent on the life-
time of programs.
When using the X11 standalone driver, on the contrary, the
window is created the first time the graphic application opens a
viewport on the X11 device, and is destroyed when the last view-
port opened on the device is closed (or when a global AGL close
operation is performed). The simpler result of this behavior is
that the graphic output disappears when the program exits.
The AGL standalone X11 driver is provided in order to allow
a to access an X11 window in the fastest possible way. The driver
will open a window when the first viewport is defined onto the
device and will close it when the last viewport is closed. Window
management capabilities are limited in that window manager con-
trolled functions (Eg.: changing window size) will yield unpre-
dictable results.
The driver allow the concurrent use of up to five (5) diffe-
rent windows.
DEVICE SELECTION
Device selection is made as usual when the viewport is
opened as in the following examples:
AG_VDEF("x[.geometry]:",.......)
AG_VDEF("x0[.geometry]:",.......)
AG_VDEF("x1[.geometry]:",.......)
where geometry is a standard X11 geometry specification of the
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 53
form:
[<width>x<height>][{+-}<x_position>{+-}<y_position>]
[] enclose optional parts
<> enclose numeric values
{} enclose choice
Example:
AG_VDEF("x.500x400+200+300:",.......)
Opens a 500x400 pixel window with upper left corner placed
200 pixels from the left border and 300 pixels down with respect
to top border.
The AGL names of the X11 device ('x', 'x0', 'x1', in the
above example) are, as usual, declared in the file "agldevs.dat"
by means of lines as follows:
x:x11.AGL_x11 # Use direct X11 driver (default
# window 0)
x0:x11.Window0 # Use direct X11 driver (same
# default window, but different
# name)
x1:x11.AGL_x11.1 # Use direct X11 driver, window
# number 1.
x2:x11.Window2 # Use direct X11 driver, window
# number 2.
where
x,x0,x1,x2 are the AGL device name
x11 is the driver name (it must have been included
into configuration).
AGL_x11
Window0
AGL_x11.1
Window2 are optional names to give to the windows (they
will appear in the window name bar on top).
USAGE HINTS
Because the window is destroyed (i.e.: disappears) when no
viewports are left opened on the X11 device, if within a single
application it is required that the window remains opened until
finished and the application is opening and closing viewports, it
may be useful to open a dummy viewport at the beginning which is
never closed so that other viewports may be opened and closed at
will without destroying the X11 window on the screen.
If an application requires that the window survive after the
end of the program, the "generalized window driver" and the
related X11 server must be used instead.
Aug 1 14:57 1994 AGL Devices - Vers. 3.61 Page 54
