The code on this site is obviously available to anyone who chooses to download it. It is however copyright by its author, Walter F. Taylor. It is not guaranteed in any way, either as to its suitability for any use, or as to any performance standard. The programs are in easily-inspected ASCII code. The C-code is quite transparent, and it is easily seen that the programs take no action besides writing to standard-output. Therefore, any modestly trained person can see that they are virus-free. However, making that determination is ultimately up to you. In fact, as far as I know, there is no way that this material could directly harm anything, but nevertheless, you use it at your own risk.
You do not need all the programs offered here. Two or three will suffice for everyday use. Your choice of programs from this menu will depend somewhat on your scenario for computing (see Scenarios ). If you adopt the pure-simlab scenario, then to_ps.c will suffice. If you work purely on Pc's, then to_pdf.c will suffice.
Borland users note: I have compiled to_ps.c and to_pdf.c on Borland in Math 217, and they appear to work fine. You should do your own compiles of these. You must redefine UNIX as 0, right near the start of the program. With "build all" you get an executable file to_pdf.exe. I found that I couldn't do the build on the a:drive, but I could later copy to_pdf.exe to my diskette on the a:drive. If you do this, then you have to_pdf ready to use wherever you are. A typical command might be
a:to_ps < mydata.di > mypicture.ps(or, there are so many other ways you could line things up.)
Unix users note: the two most useful files are already compiled. In my home directores (~wtaylor) on simlab and on rtt, you will find executable files to_ps and to_pdf. These are compiled versions of to_ps.c and to_pdf.c. (Hopefully I have correctly set the permission for you to use them.) Therefore you can use them directly. A typical command would be
~wtaylor/to_ps < mydata.di > mypicture.ps(or, there are so many other ways you could line things up.)
Here is Figure 6.44 from page 401 of the book - in a device-independent file (as described on pages 89 and 107 of the book). Without further work, you can't view it as a picture, only as a file of device-independent graphics commands. (It is very long, but in fact you get the drift of it from the first fify lines.) To see the picture on your screen, you will have to translate it using one of the translators that follow. To accomplish this will be one good preliminary test of your understanding of our tools.
to_ps.c -- C-code to change .di to .ps -- Here .ps stands for Adobe's PostScript language (see pp.93-94), and .di stands for the device-independent code described on page 89 of the book. (It also recognizes those on page 107, plus colors, plus a few more. Read the "switch" clause of the code to see the full lineup.) This is (an augmented version of) the program described on pages 96-97. It has one extra feature that is sometimes useful. If you use any editor to look at the last few lines of the output, you will see a recommended window size.
to_ps.c, ANSI standard version, -- code written 9/00, and not thoroughly tested. This code apparently may also be compiled as a C++ source, at least if you don't ask for the unix time-stamping features. Use at your own risk.
Under unix, the programs to_ps.c and to_pdf.c also stamp their output files with the username and the date and time, along with a description of the program to_ps.c that created the output. These are all comments that will not appear on the final hardcopy of your picture. It is also a good idea to name-stamp your pictures. This is handled by the file routines.c that is found in prototypes.
to_ps_abbrev.c - C-code to change .di to more compact .ps This has the same effect as to_ps.c, but the .ps code produced is more compact. This compactness is achieved through the use of definitions, e.g. m for moveto. (You can see the definitions right near the start of the file.) Some networks are fussy about how big a file you can transmit. This might be useful in such cases. (PS -- an error was discovered Sep 15; if you downloaded before then, you should redownload.)
to_ps.awk - awk-code to change .di to .ps. See page 101 of the book. Its overall functionality is the same as to_ps.c, just a different language, awk instead of C. Well, some people like awk. Awk can be found on unix machines, as well as a manual entry (do 'man awk'). If you like it, you could modify it to do some of your other work, such as bezier curves and splines.
to_ps.p - same as to_ps.c, but pascal code. Nobody has written this. If you are fluent in pascal, it should not be difficult. But anyway you hardly need it.
ps_envelope - A .ps envelope that will change .di to .ps. Nice to see that it can be done; somewhat non-intuitive, and fussy to use. It contains comments explaining its use. With some care, it is suitable for use by rather naive users. Warning: in this setup you cannot append comments willy-nilly to commands; you may only make comments with %.
to_pdf.c -- same as to_ps.c, but outputting PDF-code. (Adobe's Portable Document Format ). The advantage of this language is that almost every relatively new PC has an Acrobat Reader built in. I am not an expert in PDF, but I think I have written something that will work for us. It has a few gaps - for instance, i didn't implement a command for "clip region," or for "dot." If you encounter any errors, let me know. The code produced is somewhat sketchy PDF: Acrobat will give you an error message "repairing file." Apparently this is harmless.
to_pdf is now available in an ANSI standard version, which may also be taken as C++ code.
Colors in .ps and .pdf -- warning. The .di commands
w 0.0 0.0 1.0 1.0 C 1.0 .0.0 0.0 m 0.2 0.2 l 0.8 0.8have different effects under to_ps.c and under to_pdf.c. The resulting .ps file displays as a red line segment. The corresponding .pdf file displays as a black line segment. This difference goes back to inherent difference in .ps and .pdf. With enough expertise, it might be possible to modify to_pdf.c to avoid this discrepancy. On the other hand, for the time being, it is best not to rely on m and l commands to supply color. A .di file like
w 0.0 0.0 1.0 1.0 C 1.0 .0.0 0.0 L 0.2 0.2 L 0.8 0.8 L 0.2 0.8 qwill make a red triangle both in .ps and in .pdf
ps2pdf. This is a unix command. If you need a really precise pdf file, use my to_ps.c followed by this unix command. For the precise syntax of ps2pdf, consult the online manual entry. This is available on rtt, but apparently not on simlab.
to_math.c - c-code to change .di to .math. Here "math" means mathematica. This allows you to use mathematica as a viewing engine, if for some reason you have no other way to view .di.
to_tek.c - c-code to change .di to .tek. (Tektronix code.) I haven't seen a tektronix terminal for a long time, but you might just find one somewhere. (Tektronix tubes are - or anyway used to be - pretty crude. Only the most basic features work in this code.) P.S. 10/1/99. I just discovered, somewhat by accident, that at least in one version of X-windows, an x-term window can be switched to Tekronix mode, by pressing Control plus the middle mouse-button (which gives you a menu). Nevertheless this is of little use, because if you have X-windows available (as in Simlab, for example) then you also have ghostscript, which is better than Tektronix.
to_pc.c . - Turbo C-code to display .di directly on a PC-screen. Definitely a work in progress. This version works under Borland. (As of 9/22/99.) So far I have only been able to make it work with integers. (I have been unable to get Borland to walk (do the BGI interface) and chew gum (scan floating-point numbers) at the same time. (This was possible under Borland's ancestor called Turbo-C, even ten years ago, but today I cannot make it work.) Maybe somebody knows how to do this. In any case, with .pdf available, to_pc is redundant, but it is nice to know it can be done.
The aspect ratio of to_pc.c is not quite right. A circle comes out looking like an ellipse. It is obvious how to fix it, but I have not done it yet. This effect may be machine-dependent.
Instructions: your project should ask for a DOS executable, calling for the BGI library, and, under "expert," asking for the main to be in C-code. Then it should compile and link with no effort. If you have a file xxx.di, with all coordinates in integers, then in a DOS window, you can command to_pc < xxx.di Your screen will show the curve. So far this only works for m and l commands.