Announcement of release 4.1 of GPLOT/GTEX 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 : There is an anonymous FTP available on GODOT.PSC.EDU (128.182.65.7), a HARRIS running UNIX, with both a tar file and a src directory. For VMS users there is an account DUMMY, password ANONYMOUS on AJAX.PSC.EDU (128.182.66.109) with a backup file GPLOT.BAK, block size 2048, also sources. PK files (if you want them) are on AJAX in USR$ROOT:[ANDREWS.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 Simple UNIX makefile, there are assroted other makefiles for X, SUN, etc., look thru the directory 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: VMS UNIX Meaning /device=foo -dfoo device foo /diaquest=foo -vfoo use diaquest on port foo /copies=n -cn make n copies /debug -D output debug info /list -l output a listing file (.lis) /pxl_in=R -PR R pixels per inch /ypxl_in=R -QR Q pixels/in in y direction (if different from x) /screen=foo -sfoo same as /dev=foo/tty /tty -t use tty controller /x_offset=R -xR shift x origin R inches /y_offset=R -yR shift y origin R inches /x_size=R -XR output X size R inches /y_size=R -YR output Y size R inches /included -i output to be included in other file /index -I show index, if supported /degrees=R -rR rotate R degrees anticlockwise /pages=s -ps pick out subset of pages, e.g. /pages="12_15,-4_10" /clear -C Clear Text input file 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 should 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. Indexing: An experimental indexing scheme is in force under VMS. If the GPLOT CGM Binary driver is used to create an output file then index blocks pointing to different pages will be created using an Escape element with a negative index. If GPLOt reads such a file it can uses these index blocks to create a "table of contents" that can be read with the /index option. The /pages option will run much more quickly, also. If no problems are seen I will extend this to UNIX soon. INDEX.TEX is a quickie description of the index blocks as they stand now. 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 Example TeX files: vmsdemo.tex Example of mixing teX and graphics on VMS unixdemo.tex Example of mixing teX and graphics on UNIX Legal Status of code: GPLOT is not public domain, shareware, or any other kind of ware. 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 headers, so long as they can be uniquely identified. Forthcoming attractions: There are still a half dozen elements I have never seen and few more that I'm probably not handling correctly, I hope to clean them up. The GKS, SUN and X11 drivers were not done by me and may not allow the inclusion of cgm files in TeX documents. I now have access to a GKS machine, an X windows device and a SUN is coming, so I hope to unify the inteface soon. I should have DECWindows, NEC dot matrix and IRIS drivers soon also. Incompatible Changes from last release: For old timers, there have been two changes to the driver interface; the marker type is now passed as an integer index rather than a char, it should have been that way in the first place. See the CGM sdandard, or defs.h for the integer codes. Also, the best x and y sizes for the output page (in pixels) are now pased as the last two arguments to the Begin Picture Body routine. This allows windowing systems to take advantage of their capability for resizing, e.g., if the image is tall and skinny, a tall skinny window will do. Hardcopy devices can use this for centering if they want. Log File: If the macro USAGE_NAME is defined for the module io.c at compile time (UNIX), or if the logical GPLOT$USAGE exists (VMS) GPLOT will attempt to keep a log inthat file of any use. It presently write out 1) the command line (with a 1 in the first column) 2) the metafile descriptor (if any), (with a 2 in the first column) 3) CPU time, elapsed time and number of pages (3 in first column) the opening number is always followed by a space. -Phil Andrews andrews@b.psc.edu, andrews%cpwscb@clipr.psc.edu, andrews@godot.psc.edu