All Databases MacTech Vol 04-1988

PicComments

Volume Number: 4

Issue Number: 12

Column Tag: Assembly Lab

Inside PicComments

By Raul Tabasso, Rome, Italy

Inside PicComments

Everything you’ve always wanted to know about picComments but were afraid to

ask.

Raul Tabasso is currently working on his thesis in Architecture at the University

of Rome where he was particularly involved in designing a CAD system. At the end of

1984 he started developing software on the Mac and since then it has become his

principle activity. At the moment he is working on a large project, a Macintosh

application written in assembly language that will eventually allow bitmaps (like

those digitized with scanners) to be transformed into a collection of objects as in a

PICT file. In his younger days Raul worked for a week as a bicycle messenger in San

Francisco where he learned how to overcome slopes.

When I first read the Laser Manual and Apple Technical Notes on the subject, I

was very surprised to see how easy it seemed to implement some laser specific

features without the bother of sending a special PostScript (PS) program to the

printer. Actually the idea of passing information to the laser driver through picture

comments not only makes it very easy to include some features in your programs, but

guarantees longevity and stability to your code utilizing the power of PS through

QuickDraw (QD). In fact even if one day this technique could be replaced, Apple will

hardly change the rules its own applications and many others depend on. This is at least

if you don’t take picComments (from now on picComs) just like a trick to send your

own PS programs which, although it now works, could really break the rules of device

independence.

If you have experienced picComs you probably realized that, despite revisions,

Apple’s own documentation surprisingly lacks precision and clearness in more than

one point and that such a brilliant idea appears not to have been supported as it should.

Since a lot has been already written about picComs I am not going to repeat basic

information most of us already read but I will concentrate on the more obscure and less

sampled aspects. For example one of the most exciting features of picComs is the

ability to have easy access to PS equipped printer’s capability to smooth polygons

using bezier curves. As far as I know (you can check how far in the bibliography),

nothing has ever been shown about printing smoothed polygons using this scheme.

Furthermore we will examine the inner working of one more ‘unrevealed’ picCom, the

SetLineWidth.

• Please note that through this article we will use the term laser or laser driver for

convenience where we shall actually be referring to any device and driver that can

process picComs. Seemingly the term imagewriter will be referred to those devices

and drivers ignoring picComs. Moreover, since there is no reason your application

can’t make sure it is running on a recent driver, I cannot guarantee everything will

work as described in this article using earlier versions of the 4.0 laser driver •

Figure 1. Sample Smoothed Picutres

A Different Approach

Before we get involved with smoothing, there is something to point out on sending

picComs to the printing grafPort that I think is fundamental and seems to have been

left out of any discussion. You probably noticed that all the examples published are

structured something like this:

myPic := OpenPicture(theWorld);

DrawStuff; {with QD + picComments}
ClosePicture;
PrintThePicture;   {go print myPic}

This will work nicely in an example test or in a small program, but in a real

application will probably give you some problem. Why? Very simple. Since you

usually give the freedom to your users to draw as many polygons or rotated texts as

would fit in the available heap, it can easily happen that there isn’t enough memory to

make a picture containing all graphics to be printed or saved.

So what to do? Can we divide the picture into smaller ones? If so we must create

and kill pictures in the middle of the printing loop, and this is not allowed as specified

in IM2 (p. 160) where they warn us: “Don’t call the QuickDraw function OpenPicture

[] after a call to prOpenPage ”. Do we have to open a picture in order to use

picComs? Although we usually must, when printing we do not really have to.

Let’s have a look at some facts now and see why this is possible. When we are

spool printing on an imagewriter, the driver is actually writing a PICT format file on

the disk (or possibly to memory). To accomplish this, it has to solve the same problem

we just talked about, as nothing guarantees that it will have enough memory to

accumulate the picture and eventually print it. Fortunately, it is possible to customize

the standard QDprocs, the low-level bottleneck drawing routines of QD. The

imagewriter driver customizes the stdPutPic procedure (in the PrOpenDoc call) in

Referenced by (10):