Amiga ISO Collection/AmigaUtilCD1.iso/GFX/Converter/PTC-AEAO.LZX/AddOn.lha/POST/GPlot/gplot.txt

Text File | 1996-07-06 | 19.0 KB | 442 lines

Announcement of release 4.3 of GPLOT, Halloween '90
Changes since 4.23
----------------------------------------------
New features:
GUI's (Graphical User Interfaces), GPLOT now includes a MOTIF interface
in addition to the existing DECWindows, Athena Widget Set and Suntool
interfaces.

If the device "psc" (-dpsc or /dev=psc) is selected, GPLOT will produce
full colour PostScript output, using the colorimage operator for
cell arrays. The "ps" device will use colours for polygon fills but not for
cell arrays (uses a greyscale) or lines (monochrome).

GPLOT appears to run quite happily on the new IBM RS6000 series using the
MOTIF or ATHENA interfaces and an XLIB driver, or from the command line
with the IGL driver.

GPLOT now clips as it should, using device capabilities if present
(PostScript and X) or a particularly stupid fallback algorithm if not.

There is now full support for making movies with the Sony LVR video disk
recorder, the device controller module was implemented by Grace Giras and
Anjana Kar and includes the management of an on-disk directory.
New files associated with this are lvr.c, lvr_io.c and lvr_defines.h

Any of the X-based interfaces (gplotm, gplotaw, gplotdw) can be loaded with
either of 2 XLIB drivers; xl.c (default) or xws.c (details in makefile).
There is a complete separation of interface and imaging model, display
postscript will also be an option soon. The xl driver does not ask for
any colour tables to be loaded, it merely asks the window manager for the
closest possible colours; thus it will co-exist with any other simultaneous
applications. It is a little faster and is appropriate for simple pictures.
The xws driver asks for particular colour tables and is better for
complex pictures requiring precise colours (e.g., scanned images) but
may make other portions of your screen look strange.
Run-time selection should be possible in a future release.

Bug fixes:
A strange bug affecting line widths on multiple-page DISSPLA cgm files
has been fixed. A couple of bugs specific to SUN's have been fixed.
I try as hard as possible to produce reasonable output when the
background colour (via index 0) is changed after the beginning of the
picture body, but there may still be strange output on some devices.

--Phil Andrews

(here follows the last release notice, just to embarass me/enlighten you)
Notice for release 4.2
------------------------------------------------------------------------
Changes since 4.2
----------------------------------------------

New interfaces: gplotdw.c, gplotaw.c and gplot_suntool.c are new
DecWindows, Athena Widget and SunView interfaces respectively.  They
should be considered work in progress and do not yet offer the full
functionality of the command line interface, but they do offer the ease
of "point and click" use.  Check with the makefile to see what you want
to build.  DecWindows will soon become MOTIF and an OPENLOOK interface
should be here soon. gplotaw and gplotdw use the new xl driver, which
is also work in progress, particularly in the areas of colour tables and
cell arrays. The interface to the main routines is wint.c.
gplot_suntool.c uses the sv.c driver.

Bug fixes: there are fixes relating to left handed co-ordinate systems
(MAC CGM's), zero default line widths, real VDC's, binary to clear text
conversion, and others. A bug in the interaction between GPLOT and
CGMGEN which reduced sizes by a factor of 32 has been fixed. If your
favourite bug has not been fixed send mail to [e-mail]

Compatibility with NCAR 3.0: this GPLOT will read NCAR 3.0 files,
though there is an ambiguity there (changing the background colour
after the page begin) which will produce different output on different
devices. Also I have had to disable appended text processing for NCAR
files since NCAR files seem to set (incorrectly) the NOTFINAL flag for
all text strings.

Not yet done: in order to handle both screen displays and publication
quality GPLOT presently uses both raster and vector fonts.  I hope to
replace both of these with Adobe type-1 fonts as soon as possible:
until this is done, text processing is pretty much frozen.  The freeze
includes GTEX which I hope to convert to adobe type-1 also.  There are
still a few emulations missing: mostly ellipses, should be in next
release.

--Phil Andrews

(here follows the last release notice)
Notice for release 4.2
------------------------------------------------------------------------
GPLOT is a CGM (Computer Graphics Metafile) processor. CGM files come
in 3 flavours, Binary (dominant form), Clear Text (human readable), and
Character (more compact than Clear Text, but only 7 bits used per byte)
encodings. GPLOT will interpret and create Binary and Clear Text files,
I have not yet had requests for character encoding.
GTEX is a companion TeX DVI interpreter, it uses the same device
drivers as GPLOT but is much smaller and simpler.

GPLOT and GTEX are entirely in C, and will compile and run under UNIX
(BSD, ULTRIX, UNICOS) or VMS, there is a heavy use of #ifdefs.

Where to get files (note new addresses !):

There is an anonymous FTP available on CALPE.PSC.EDU (128.182.66.148),
a vaxstation running ULTRIX, with both a tar file and a src directory.
For VMS users there is an anonymous FTP on B.PSC.EDU (128.182.66.102)
and A.PSC.EDU (128.182.66.105), our VAX 8810 front ends.  The source
files are in TEX$ROOT:[GPLOT] with a backup file GPLOT.BAK, block size
2048 and a full set of .pk fonts (if you want them) are in
TEX$ROOT:[PK...].


The source files involved are

gplot.c        Small controlling module
cgm.c        Binary CGM interpreter
ccgm.c        Clear Text interpreter
io.c        I/O routines
utils.c        Utility routines
devices.c    Interface to device drivers
defs.h        common definitions
ccdefs.h    clear text names, etc.
emul.c        emulation package
gpt_commands.cld     VMS CLI interface command file

cgmb.c        Binary CGM driver
cgmc.c        Clear Text driver
ps.c        PostScript driver
tek.c        Tektronix driver (various flavours)
uis.c        DEC windowing system
xws*.c        X11 driver
sundriv.c    SUN CGI driver
peritek.c    Peritek frame buffer driver
qms.c        QMS (QUIC) driver (beta test)
gks.c        DEC VMS GKS driver

carray.c     Cell Array utility routines
drvcla.c    Cell Array utility routines

tty.c        terminal controller module
dq.c        Diaquest controller

pkras.c        TeX .pk format font file decoder
hload.c        Hershey font loading module
hload.h        Hershey font definitions
hfonts.bin    raw Hershey fonts
hfonts.c    produces hload.h
hfonts.h    defines Hershey font order

gtex.c        TeX dvi file interpreter
cache.c     Caching for .pk fonts (currently turned off)

descrip.mms    VMS mms file
makefile    UNIX makefile, some assembly may be required for your
        specific uses.


Binary CGM issues:

Headers:
Headers are an unfortunate fact of life; many sites have interpreted
the CGM standard to allow an arbitrary record structure and routinely
have a private format header before the CGM file proper. GPLOT knows
about Los Alamos, "Military" and NCAR header formats. Any other format
will probably result in an "unknown header" message and termination.

Byte ordering:
This can also be a problem, resulting from network transmission or just
poor coding. GPLOT tries a number of different permutations while
simultaneously looking for a known header or legitimate Begin Metafile
element.

Bad record formats:
I have seen a number of binary CGM files on VMS with CR record
attributes ! On VMS I take care of this by ignoring record attributes,
but if such a file was moved to UNIX it would probably be unreadable.
This is very poor coding and should be discouraged.

Note that on VMS any strange format CGM binary file can be converted
to a generic form (512 fixed record, sequential, no record attributes,
no header) by running thru GPLOT with /dev=cgmb. It can then be moved
thru networks as a binary file.

Modifications to GPLOT:

GPLOT was designed to be easily modified in two areas, one is at the
driver interface. To add a new device driver, a small addition need
only be made to devices.c and the new device driver linked in. Details
on request (or you can look at CGMB.C and PS.C to see how it's done).
The second place is at the controlling module GPLOT.C. The main body of
GPLOT needs only an open input stream, (possibly) an open output stream
and a command line. This makes it possible to use GPLOT to include
graphics from CGM files in other output, such as TeX files. GTEX.C
includes such an interface, and that interface can be used to drive any
of the GPLOT device drivers, including the Binary and Clear Text CGM
drivers. This is how we add CGM drivers to existing packages at PSC.
If you have to modify/read the command line, do it at the GPLOT.C or
device driver level, it is parsed in UTILS.C and the code there (that
parses both VMS and UNIX style lines) has made strong men cry.

Fonts:

GPLOT knows about 2 types of fonts, raster-style Metafont created PK
format fonts and Hershey vector fonts.  Raster fonts are handled by
PKRAS.C, these are slow, require the presence of many disk font files,
and may not be rotateable or scaleable.  However, they look good and
will fit nicely with GTEX produced output files which use the same
fonts.  Under VMS PKRAS looks in TEX$PK:[MAG]for the .pk files, where
MAG is the magnification in TeX style units (1000 = ten point font at
300 pt/in).  Under UNIX it needs to be told where to look with a
compile-time definition, look in the make files.  If you intend to use
.PK files you obviously know enough so that you shouldn't need any help
from me.  GTEX must use .PK files since TeX requires them.  TeX is much
too tightly coupled to a particular font type for its own good.

The Hershey fonts are preloaded, are fast and can be easily scaled and
rotated.  HFONTS.BIN is a binary file containing the descriptions for 19
fonts.  HFONTS.C and HFONTS.H are files which extract a subset of these
fonts from HFONTS.BIN and produce HLOAD.H.  When HLOAD.C is compiled it
sucks in HLOAD.H and produces an object file that is linked with GPLOT
to give it a preloaded set of vector fonts, got all that ?  HFONTS.C can
be easily altered to set the number of fonts preloaded and their
default order.  The present setting loads SIMPLEX ROMAN, COMPLEX ROMAN,
TRIPLEX ROMAN and COMPLEX GREEK.  These 4 fonts take up about 20Kb, all
19 take about 100Kb.  If you're happy with the defaults you don't have
to rerun HFONTS, just take HLOAD as it is. I highly recommend the
Hershey fonts over the .PK fonts, we use the .PK fonts only for
presentation movies.

Installation:

The first step is to decide what device drivers you want. DEVICES.C
should be compiled with those turned on so that you don't get a
link-time error. Look at descrip.mms and the makefiles to see how that
is done (e.g., cc devices.c/def="incps" turns on PostScript). You will
probably want the tty controller but not the diaquest one (a controller
allows interaction with an outside agency at, e.g., the end of page).

There are several makefiles available, depending whether you are
building this for a SUN, X11 etc. Look thru them.

Under VMS GPLOT and GTEX are both installed as symbols, e.g., GPLOT :==
$USR$ROOT:[ANDREWS]GPLOT, the CLI parsing is done internally.

Command line:

GPLOT and GTEX share the same command line processor, under VMS the
format is GPLOT input_file [options]
the input file extension defaults to .CGM (GPLOT), .CGMC (GPLOT/CLEAR)
or .DVI (GTEX).
Output extension is governed by the device.

Under UNIX it is
gplot [options] input_file output file
output file defaults to stdout, if input_file is "-" then input will
come from stdin.


the options are described in gplot.hlp and gplot.man
Note that not all options will work on both GPLOT and GTEX, nor with all
output devices.

Under VMS GTEX will look for
the logical TEX$OUTPUT if no input file is specified, both GPLOT and
GTEX will point the logical GPT$OUTPUT at the output file. Under UNIX
both input and output can be piped.

Documentation:

This is most of it. We had other documentation, but it got out of date, I am
rewriting it. It may be ready for the next release. We do have:
GPLOT.HLP a VMS help file which includes UNIX man pages entry and
GPLOT.MAN a standalone GPLOT man page.

Example files:
Due to Space limitations example files may not be in the backup and tar
sets.

Example CGM files:

smpl07.cgm        DI-3000 file
cgmbin.cgm        DISSPLA file
cgmgen_test.cgm        PSC test file
example_1.cgm        NCAR file
station.cgm        Movie.BYU file

Legal Status of code:

GPLOT is not public domain or shareware.  Every
module is copyrighted and you are being given free license to do
whatever you want with it at your site, or to redistribute TOTALLY
UNCHANGED AND WITHOUT CHARGE (except for reasonable media cost) to
someone who can't get it any other way.  It is is copyrighted for 3
reasons

1) So that some company can't put their name on it, maybe copyright it and
then sell it. It does happen; it happened to me, it happened to NCAR.
This is annoying.

2) It's policy at the Pittsburgh Supercomputing Center. This is wise.

3) So that I don't spend the rest of my life chasing down bug reports
from redistributed, hacked code, perhaps with spurious version numbers.
Also so that I can make sure everyone has the current version. This is
essential.

If anyone wants to make a complete new device driver and redistribute
it, that's fine since it should have no interaction with the rest of
the system.

Bug reports:

I want 'em. I am most interested in CGM files that contain elements, or
combinations of elements, that I have never seen and may not be
handling well. I am not interested in people who give me back 20,000
lines of code and say "I've modified it to be better, why don't you use
this", I do want reports that tell me I have a bug in line such and
such, perhaps with a fix. I'm also interested in any new cgm headers, so
long as they can be uniquely identified.

-Phil Andrews ([e-mail])

With this release, maintenance of GPLOT will be taken over by Anjana
Kar, [e-mail]. Please send requests/bug reports to her, but be
gentle, she is saving my life here.

Changes with Release 4.2 of GPLOT
--------------------------------

New Drivers

New device drivers are IGL, the Silicon Graphics IRIS GL driver,
EXCL, the ANSII printing language used by the Talaris 1590 laser
printer, the QMS, QUIC programming language used by the original
QMS printers. Note that when there are raster images involved the
QMS800 and QMS1200/QMS2400 require different formats, in that case the
device requested should be explicitly QMS800 or QMS1200.
The TEK4107, Tektronix 4107 colour terminal.

New Capabilities

There are now general routines for handling direct colour and arbitrary
cell arrays; these allow the UIS and Tektronix drivers much greater
capability. I intend to freeze the UIS driver with this release and
provide a DecWindows driver with the next release.

New Options

There are presently four types of fonts that may appear in GPLOT
output, 1) fonts that are known to the original graphics packages and
are converted by it into Drawing Primitives. Examples of these are the
vector fonts used by DISSPLA and (optionally) by NCAR. There are also,
2), hardware or firmware fonts belonging to the output device, 3),
Hershey Vector fonts known to GPLOT and normally loaded with it and 4),
optionally raster fonts in PK format kept on disk. In the output from
a single CGM file there may be mixtures of fonts depending on the
setting of various flags by the CGM file. There is now an option to
override these flags and force the use of a specific font type.
GPLOT/FONT_TYPE=0 (on VMS) or gplot -f0 (UNIX) will force the use of
output device fonts everywhere possible,
GPLOT/FONT_TYPE=1 (on VMS) or gplot -f1 (UNIX) will force the use of
Hershey vector fonts everywhere possible and
GPLOT/FONT_TYPE=2 (on VMS) or gplot -f2 (UNIX) will force the use of
PK raster fonts everywhere possible.

For installers of GPLOT, to use Hershey fonts GPLOT must be linked
with the hload object file and the symbol "inchershey" must be
predefined for the utils source, e.g., CC/DEFINE="inchershey" in VMS
and cc -Dinchershey in UNIX. For the PK raster fonts utils must be
compiled with incpkras defined and gplot limked with the pkras object
file. Both Hershey and PK raster fonts can be linked simultaneously.

The size of the fonts is often different from what the user expects
particularly with NCAR CGM files.  This can now be changed at runtime
with GPLOT/TEXT_MAG=1.3 (VMS) or gplot -m1.3 (UNIX), say to magnify the
fonts by 1.3, or any other real number.  This will only have effect if
the fonts were not already converted to graphical primitives by the
orignal graphics pakcage.

One thorny problem has been with the Scaling Mode Picture Descriptor
Element. By default pictures are described in an arbitrary space which
GPLOT rescales to fit the dimensions of the output device, the Scaling
Mode element can prevent this by requiring that the output be scaled by
a particular factor, so that it will always be the same size on any
output device. Unfortunately this may prevent the use of some output
devices. Complications arise as every CGM file produced by
DISSPLA requests a definite scaling factor, which is extremely
inconvenient for normal use. Thus in the past I have simply ignored the
Scaling Mode element. However, legitimate uses of this element (e.g.,
engineering drawings) have occurred and as I try to move GPLOT to a
fully conforming interpreter I have now implemented the Scaling Mode
element. To allow normal use of these files it is possible to override
this element at runtime, GPLOT/SCALE (VMS), or gplot -S (UNIX) will
allow gplot to ignore the Scaing Mode element and scale output to fit
the output device dimensions.

Indexing CGM files

If the GPLOT CGMB driver is used to produce a binary file, index blocks
(on both VMS and UNIX) will be included. Thes follow a format adopted
by the SLATEC graphics subcommitted and allow random access to the
frames in the CGM file.

The index blocks are encoded as escape elements (index -64).

The format of an index block is

No. of pages in this block         (n, non-negative decimal integer)}

then repeat n times
page number                 (p, decimal integer)}
string length                (q, non-negative decimal integer)}
one space character
page string                (q characters)}
offset to next index block        (decimal integer)}

e.g. the string ``2 530 10 first page 1520 11 second page 2048''

If the index offset is 0 then this is the last index block.

The offset is in bytes from the start of the present index block
command, and can be positive or negative.

I lay down the first index block immediately after the begin
metafile and the last one immediately before the end metafile so the
file could be parsed in either direction. Index blocks are up to 512
bytes. I allow a /index qualifier (-I in UNIX) which merely produces a
table of contents and /pages selects sets of pages, e.g.,
/pages=(1,5,20_35).

Pages can also be selected by title (if they have one)
gplot/title="Page Title" (VMS) or gplot -T"page Title"  (UNIX) will pick
out only those pages with that string in their title string.

It is possible that the index blocks could become unreliable due to
file transport or (heaven forbid !) a software bug. If that has
happened (or you know it will happen) the generation/interpretation of
index blocks can be turned of by gplot/nindex (VMS) or gplot -N (UNIX)


--Phil Andrews