| Volume Number: | 3 | |
| Issue Number: | 4 | |
| Column Tag: | Letters |
Letters 
Postscript Plotting
Philip Baumeister
Loomis, CA
As a new subscriber, let me convey thanks for a great magazine. But as many of your letters seem to contribute information, I seek it. When I write my own plot graphs, I approximate curves the quick and dirty way, with short segments of straight lines. The line itself is drawn at 300 dots/inch on the LaserWriter, but (alas!) the locations of the ends of the line are in pixel coordinates, which means that there are steps, and a resolution of only the nearest 1/72 of an inch in the location of the line. What can I do?
[This may or may not answer your question as you expected, but you might try writing two plot routines; one for the screen in quickdraw, and one for the LaserWriter in Postscript. The following sample program does this. It displays a black box with a plotted line using quickdraw on the screen in Microsoft Basic (see fig. 1). Then it opens a text file and writes a short Postscript program to the file that when downloaded to a LaserWriter, prints the same thing but in Postscript. This way you can plot at the LaserWriter resolution of 300 dots per inch. -Ed]
{1}
REM Basic Postscript Demo
REM by D. Smith, MS Basic
CLS
WINDOW CLOSE 1
MENU
MENU 1,0,0,”File”:FOR i=3 TO 6:MENU i,0,0,””:NEXT i
MENU 3,0,1,”Demo”
MENU 3,1,1,”Draw Line”
MENU 3,2,1,”Quit”
ON MENU GOSUB eventloop:MENU ON
idle:GOTO idle
‘----------------------------------------------------------
eventloop:
MenuStuff=MENU(0)
menuitem=MENU(1)
ON menuitem GOSUB Draw, Quit
RETURN
‘----------------------------------------------------------
Draw:
WINDOW 1,””,(100,75)-(350,150),4
WINDOW OUTPUT 1
GOSUB screendraw
GOSUB Postscript
GOSUB screendraw ‘ update window
MENU
RETURN
‘----------------------------------------------------------
Quit:
CLOSE
WINDOW CLOSE 1
MENU RESET
END
‘----------------------------------------------------------
screendraw:
TEXTFONT(0):TEXTSIZE(12):TEXTFACE(0)
LOCATE 3,10:PRINT “Here is a Basic Line”
LINE (10,10) - (60,60),33,bf
LINE (15,15) - (55,55),30
RETURN
‘----------------------------------------------------------
Postscript:
FIL1$=FILES$(0,”Enter Postscript File ...”):IF FIL1$=”” THEN FIL1$=”LINE.TXT”
NAM1$=FIL1$
OPEN NAM1$ FOR OUTPUT AS #1
PRINT #1, “%!PS-Adobe-1.0”
PRINT #1, “%%Title: Postscript Line”
PRINT #1, “%%DocumentFonts: (atend)”
PRINT #1, “%%Creator: Basic”
PRINT #1, “%%CreationDate: 3/1/1987 5:30 PM”
PRINT #1, “%%Pages: (atend)”
PRINT #1, “%%BoundingBox: 0 0 612 792”
PRINT #1, “%%EndComments”
PRINT #1, “%%Document prolog now follows”
PRINT #1, “grestoreall”
PRINT #1, “initgraphics”
PRINT #1, “/pageproc{} def”
PRINT #1, “%%EndProlog”
PRINT #1, “%%Line Example”
PRINT #1, “%%Procedures now follow”
PRINT #1, “/Times-BoldItalic findfont”
PRINT #1, “36 scalefont setfont”
PRINT #1, “/fillbox”
PRINT #1, “{newpath”
PRINT #1, “125 360 moveto”
PRINT #1, “0 72 rlineto”
PRINT #1, “72 0 rlineto”
PRINT #1, “0 -72 rlineto”
PRINT #1, “closepath”
PRINT #1, “0.0 setgray”
PRINT #1, “fill”
PRINT #1, “}def”
PRINT #1, “/box”
PRINT #1, “{newpath”
PRINT #1, “120 355 moveto”
PRINT #1, “0 82 rlineto”
PRINT #1, “400 0 rlineto”
PRINT #1, “0 -82 rlineto”
PRINT #1, “closepath”
PRINT #1, “0.0 setgray”
PRINT #1, “stroke”
PRINT #1, “}def”
PRINT #1, “/line”
PRINT #1, “{newpath”
PRINT #1, “130 427 moveto”
PRINT #1, “192 365 lineto”
PRINT #1, “1.0 setgray”
PRINT #1, “stroke”
PRINT #1, “}def”
PRINT #1, “%% main program”
PRINT #1, “.8 setlinewidth”
PRINT #1, “fillbox”
PRINT #1, “line”
PRINT #1, “210 380 moveto”
PRINT #1, “.7 setgray”
PRINT #1, “(Here is a Basic Line) show”
PRINT #1, “.1 setlinewidth”
PRINT #1, “box”
PRINT #1, “showpage”
PRINT #1, “%% End of Example”
PRINT #1, “%%Trailer”
PRINT #1, “%%Pages:1”
CLOSE #1
RETURN
Fig. 1 Plot a line in Quickdraw & Postscript!
V.I.P. Improves!
Tom Nalevanko
Mainstay, Agoura Hills, CA
Thank you for your coverage of Visual Interactive Programming; V.I.P. users and potential users appreciate the comparitive viewpoint that can only be provided by a multi-language interest publication like MacTutor.
Since the release of V.I.P. in January, we’ve received a number of letters from customers expressing their satisfaction and offering suggestions for improvement. Since we couldn’t answer all of these letters, we did an even better thing. We took the best suggestions and implemented them in a new version 2.1 of V.I.P. This update will be sent, at no charge, to all registered V.I.P. users in March.
The V.I.P. v2.1 update includes the following improvements:
Feature Extensions: Ability to access all fonts, ability to edit Case logic structure, use of window with “grow” box, ability to use “About ...” in apple menu, movement about the flow diagram using arrow keys, use of any ASCII character in a string, etc.
New Intrinsic Functions: err, point, toplft, botrgt, and rect.
New Procedures: draw character, string to scrap, scrap to string, get pen position, set text mode, is real font, get font name, move, line, get picture info, get window title, get active window, undo text, get text, set dlog/alert font and set print options.
Supplementary products that we have announced will be available in April. These include translators to MPW C and Pascal, Lightspeed C and Pascal, and TurboPascal as well as external procedure classes: Speech Manager, Grid Manager, Database Manager, Multi-user Database Manager and the Matrix Manager. [See the VIP article in this issue for a discussion of the LS C translator, which is now functional. -Ed]
MS Basic Compiler Code Expansion
I.N. Botnick
Los Angeles, CA
I’ve been a BASIC programmer for seven years, from the Apple II+ to the IBM PC and finally to the Macintosh. I”ve used IBM Basic I & II, QuickBasic, BetterBasic, True Basic, ZBasic and now MS Basic on the Mac. I want you to know that the Microsoft Basic Compiler for the Macintosh is one of the worse compilers I have ever used. It is unbelievable that a company of Microsoft’s reputation would put out a compiler that is so bad. Take a look at the chart below:
Program ASCII Size Compile Size Memory Use
#1 148K 375K 625K
#2 127K 327K 550K
#3 111K 293K 525K
#4 93K 254K 475K
Each of these programs was designed to run in 330K to 465K of memory, but as you can see, the compiler is generating unusually large code. One main reason is because they are putting 8 bytes in front of each statement for error and event trapping. Program #1 has 8300 statements but only 2550 lines. In all my years of programming, I have never seen a compiler that produced a 375K executable program from a 148K ASCII file! With this version, I still cannot:
1. Run a program from a compiled BASIC program.
2. Read the names of files on a disk and load them into an array.
3. Get the amount of space available on a disk.
4. Create a folder
5. Delete a folder
6. Find the name for a volume without using the FILE$ statement.
7. Set a volume’s name.
8. Find the size of the current screen. (New Macs, remember?)
9. Use color (New Macs?)
10. Init a disk.
11. Get the name of the current printer.
12. Get the name of the file that was clicked to launch the program.
13. Open an included library without a fixed path name (a Macintosh No-No!)
Microsoft Responds
Art Schumer, Program Manager
Microsoft Corp.
As the new Program Manager for Macintosh Languages here at Microsoft, let me thank Dave Kelly for the fine review you wrote in the February issue on our new interpreter and compiler and may I respond to some of the bugs you and your readers have uncovered and which you communicated to me in your recent letter.
Terminal Program: We are actually aware of three seperate problems with the communications port. We are working to fix these problems. We have a patch for one of them.
Default Window: Your right! The display of a default window is annoying in compiled programs. This will be addressed in the next major release.
Zoom Box Support: This will be added to the present method of double-clicking on the title bar in the next major release. Ditto for the compiler.
Large Code Size: We are investigating ways to shrink code size and hopefully will be addressing this in the next major release. It’s not unusual to expect a 3 to 1 expansion in any language from source to compiled form. However, I would like to see it reduced as much as possible. Sharing the runtime module with a number of programs can save 40K.
HFS: Major enhancements to the way HFS is handled in both the interpreter and compiler will be addressed in the next major release.
Undocumented features: TextEdit support was built-in to BASIC at the last minute mainly in response to one of your articles. It was too late to include in the manual but certainly will be documented further in the next revision of the manual. We would like to invite Dave Kelly and Dave Smith to discuss our future plans for MS Basic and to get any suggestions you have as to features you would like to see implemented. [We accept. Ok, gang, here is your chance! Send in your wish list on MS Basic and we will present them to Microsoft. -Ed]
Turbo Bug
Tim Votaw
Anaheim, CA
I stumbled across something recently that I can’t seem to figure out so I thought I’d pass it along to you and your readers. It seems that Turbo Pascal allows division by zero at compilation time and hence produces a nice system crash (ID 4) in your program, although the resume function seems to recover you.
[We checked this error in the latest Turbo Pascal copy, version 1.00D, just sent yesterday to our offices. While this new version is supposed to fix some bugs with the floating point routines, it does not fix this one. Here is the program:
{2}
program divbyzero;
{$U-}
{Turbo Pascal 1.00D version}
uses MemTypes, QuickDraw, OSIntf, ToolIntf, PasInOut, PasConsole;
var
thenbr,zero:integer;
begin
zero:=0;
thenbr:=0 div zero; {this line compiles & executes ok!}
writeln(thenbr);
thenbr:=1 div zero; {causes system crash ID=04.}
writeln(thenbr);
end.
When we ran this program, it compiles and executed! The first division by zero wrote “0” to the window, but the second one produced a system crash with ID 4. When we hit the resume button, Turbo then trapped the error and reported a division by zero error. We then compiled the program to disk and it also produced a nice stand alone application, that when executed, displays a nice system crash although the resume button returns to the Finder. The listing below is the same program in LS Pascal:
{3}
PROGRAM divbyzero;
{LS Pascal Version}
VAR
thenbr, zero : integer;
BEGIN
showtext;{get default text window up}
zero := 0;
thenbr := 0 DIV zero; {This line won’t compile!}
writeln(thenbr);
thenbr := 1 DIV zero;
writeln(thenbr);
END.
We tried the same program in LS Pascal to see what it would do. The program correctly
refused to compile at the first division by zero statement. We had to change zero to a 1 to
get the program to compile and execute. Obviously, LS Pascal has better error checking
at compile time. (See fig. 2) -Ed]
Fig. 2 Catching potential run-time errors
