Letters

Changes to the New Pagemaker 2.0

Aldus has released version 2.0 of it’s Pagemaker publishing program and it has become apparent that this new version differs in many ways from the previous 1.2 version. Most of the new features have been widely mentioned in the trade press previously. These include a new approach to text edit that is substantially superior to the previous method. Under version 1.2, which was written in Lisa Pascal, the resource manager was heavily used to keep track of various parts of a document, including text blocks. This apparent “over use” of the resource manager was responsible for several new System File versions as Apple attempted to fix the multitude of bugs in the resource manager that Aldus kept finding with their Pagemaker product. As is well known, the text editing of Pagemaker never did become bug free in 1.2 and the decision was made to rip it out completely and build a new text edit not based on resources. Version 2.0 was re-written from scratch in C, and so is really an entirely new product, rather than an upgrade. The obvious limitations have been fixed; the text editing is very robust now, you can have up to 127 pages, and postscript placement is now supported. Multiple pages can be added or deleted. Kearning is supported automatically. What is less well known, is how this version differs from 1.2. Figure 1 illustrates some of the differences and suggests that version 2.0 is not completely compatible with how things were done in 1.2. If you are attempting to carry on as usual from version 1. 2, you may be surprised at some of the differences.

Auto Leading Calculation Changes

The most significant difference is that the auto leading calculation in 2.0 has been changed. Under version 1.2, Pagemaker matched very closely the way MacWrite dealt with text. If you place some text in MacWrite and Pagemaker 1.2, you’ll find that the leading is nearly identical. We use times 10 pt for our text, and a mono-spaced thin saratoga 9pt. font for our source code listings in this Journal. Leading calculations for both MacWrite and Pagemaker 1.2 suggest that the leading is picked up from the screen version of the font and that this is not uniform for different fonts. However, the font differences work to the readers advantage. The leading for both MacWrite and 1.2 appear to produce a 12 point leading for times 10 pt fonts and a 9 point leading for the saratoga 9 pt font. This results in a very readable text with a tightly spaced source listing, just what you would want.

In version 2.0, the leading calculation has been changed so that it is uniform for different fonts. The leading is calculated as 120% of the font size rounded down to the nearest half point. Times 10 pt gets a 12 point leading, very similar to MacWrite and version 1.2. However, the saratoga 9 pt font gets a 10.5 pt leading, which is very airy. The June issue of MacTutor used this default leading in version 2.0 entirely and you can see the obvious wasted space in the source code listings. About seven pages of editorial was lost over the entire Journal due to this airy spacing of the saratoga font. To re-create the same effect as version 1.2, requires re-leading all the source code in the saratoga font to a 9 pt. leading, a very time consuming task.

Aldus has provided a patch so that the auto leading calculation can be changed with FEdit. The patch is given at the end of this discussion. We have tried patching the auto leading calculation to provide 110% leading. This results in tighter leading for the times 10 pt font, which makes it harder to read, and a tighter leading for the saratoga font, which takes some of the air out of it. However, the leading for the saratoga font is still not as tight as it was under version 1.2. We also tried using the 110% leading with a manual re-leading of the saratoga font listings to 9pt. This gives slightly tighter spacing than version 1.2 because the times 10 pt font is spaced tighter. Given the fact that the saratoga font must be re-leaded anyway to get the same effect as version 1.2, we are undecided as to whether the times 10 pt font would best be left at 120% leading or changed to 110% leading by using the Aldus patch. Such are the considerations you will need to go through in trying to decide if you want to patch your copy of Pagemaker to change the auto leading calculation. A future version will have this choice placed in a dialog box.

Fig. 1 Pagemaker 2.0 Changes

Tabs Changed

Another thing we have noticed is that MacWrite tabs are not being picked up the same way in version 2.0 as they were in version 1.2. We took a source code listing and set the tabs in MacWrite then placed it in version 1.2. The listing lined up correctly in a manner very similar to the MacWrite file. However when the same listing was placed in version 2.0, the comments in the source code did not line up suggesting that the tab spacing was changed. We had to manually re-tab the listing to get the comments lined up again. So there is something different about how version 2.0 picks up tabs from MacWrite compared to how version 1.2 worked.

Indentation of MacWrite and Word Files

Version 2.0 now respects the left margin setting of MacWrite files as we reported last month. This has the effect of indenting the text placement in Pagemaker, which, if you want the text to flow into the columns, leaves you with a useless column of text one inch wide as shown in figure 1. There does not appear to be any way to simply force Pagemker to re-flow the text into the Pagemaker columns regardless of the left margin setting in MacWrite. The only fix for this is to re-set all of your MacWrite rulers to move the left margin to the one inch mark. Microsoft Word files also seem to default to an indendation on the right when placed formatted in Pagemaker. However, this is easier to fix. Check the right indentation option in Microsoft Word, and set it to zero. Then the document will place correctly in Pagemaker. Aldus considers this a feature that both Write and Word files get indented according to the margin and option settings of the programs. We think Pagemaker is too particular and that more flexibility should be allowed the user in directing Pagemaker to re-flow text into Pagemaker columns regardless of margin and option settings. Another candidate for a configuration dialog directing how Pagemaker will work.

Another hidden gotcha is that Word files saved as MacWrite format from Word 3.0 cannot be placed in Pagemaker. The program either puts up a dialog box that says the file contains fonts not in the system file and refuses to place the remainder of the document, or else simply refuses to place any portion of the document. This is also true of any file created from a file saved from Word as a MacWrite file. Even if you open the file in MacWrite and save it again, you can have problems getting all of the file placed. The most effective fix is to copy the text into the clipboard and paste it into a new MacWrite file, and then place it in Pagemaker as a text only file.

Paint Files Display Bug

When MacPaint type files are reduced and displayed at actual size, the background pattern becomes a giant checkboard pattern as shown in figure 1. Apparently this is a bug. Also, the manner in which paint type files are displayed when viewing the entire screen has been changed. The paint file is not recognizable except at actual size. Under version 1.2, the display of paint files is clearly superior. Under some circumstances draw files are displayed on the screen with gaps in the text. This bug is related to the line length of the text and doesn’t seem to be easy to re-produce.

Missing Features

There are a number of features that were expected to be in this version, which have been postponed to the next version. One thing is an expanded configuration dialog that would allow the user to set the auto leading percentage, and turn off the indenting of MacWrite files so that text can be re-flowed into the column settings of Pagemaker with formatting intact without regard to the margin settings.

Now that the new system file supports nested menus, we would like to see the type menu re-done. It takes too long to change the font and size in Pagemaker because of the clumsy use of a dialog box. The font, size, style and leading could be set-up with nested menus like Scoop (Target Software’s new publishing program) uses. This would greatly speed up the process of making text changes and would allow a greater selection of style and leading options.

Automatic placement of text without having to click at the bottom of one column and then place at the top of the next column is another feature that did not make it into this version. Other features would be a clone function like FileMaker that would copy the settings and master pages to a blank document. The ability to copy the left master page to the right master page to speed up the creation of master pages is another helpful feature needed. And finally, one thing that is really needed is the ability to open more than one document at a time and merge Pagemaker files together. Now that Pagemaker can handle 127 pages, many little 16 page files could be concatenated to take advantage of the larger document size, but Aldus did not make provision for merging documents together. In conclusion, version 2.0 really represents a migration to C for Aldus, and a correction of the obvious deficiences. We look to the next version to provide the new features missing from version 2.0.

Aldus Auto Leading Patch

Using FEDit or a similar file editing tool, open a copy of PageMaker 2.0 and search for the HEX string:

3F3C 000A 3F3C 000C 3F00 4EAD

This string should be found only in one place in PageMaker 2.0: at the end of sector 3A7 and the beginning of sector 3A8. The 000A is the last word in sector 3A7. The 000C is the second word in sector 3A8 and these are the two words that can be changed to change the autoleading calculation. The autoleading value is a fraction: the numerator is the 000C (=12 decimal) and the denominator is the 000A (=10 decimal), hence the standard autoleading is 12/10 or 120%. Either or both numbers can be changed to virtually any fraction desired.

Examples:

110% leading: use 11/10. Change 000C to 000B

105% leading: use 21/20. Change 000C to 0015 and change 000A to 0014. Change the value in the corresponding sector and write the sector back to disk to make the change permanent.

Straight Story on 32K Limits

Joel West

Several letters in the June 1987 MacTutor ask about 32K limits. I’ll try to clear up some confusion on this topic.

There is nothing in the Mac or 68000 that REQUIRES a 32K limit, only shortcuts that make for more compact code if you assume a 32K limit, so if you object to such a limit, let your compiler vendor know. Certainly any compiler could have a ‘no limit’ compiler toggle to generate code without such limits. [And we can’t understand why all compiler makers do not add such a configuration switch. -Ed.]

When you talk about a “32K limit”, there are at least four separate limits. I’ll illustrate my answers using references to MPW, since that’s Apple’s official system and also the one with which I’m most familiar, but the general principles apply to all Mac development systems.

Two 32K limits relate to code references (segments):

1. The size of a segment.

The 64K ROM resource manager had a bug that it sometimes barfed for resources longer than 32K. This was fixed in the Mac Plus, and the later Segment Loaders handle longer segments just fine, so this is a moot issue (except for obsolete machines.) To quote from the MPW Reference Manual description of the Link command (MPW 1.0, APDA draft, p. 310):

  Link -ss size

“Change the maximum segment size to size. The default value is 32760 (32K less a few overhead bytes). The value size can be any value greater than 32760. 64K ROM note: Caution! Applications with segments greater than 32K in size may not load correctly on Macintosh with 64K ROMs.”

The jump table only has a 16-bit offset (within a segment) for each entry point. I haven’t tried long segments, so I can’t say whether it also plays tricks with the jump table to place dummy entry points within the first 32K--this would only be for routines called from other segments. Of course, if you only have one segment, the jump table is irrelevant, as long as the main entry point is within the first 32K.

2. Addressing within a segment.

A routine does a JSR to another routine in the same segment. The most common way is to use “Program Counter with (16-bit) Displacement” (opcode $4EBA); a 16-bit signed displacement follows the JSR opcode word This is default for MPW Pascal, C and most other compilers, and the source of the 32K limit problem.

To get around this, if you have a segment > 32K, MPW 1.0 requires that you put your programs into the segment in such an order that no inter-routine references are more than 32K apart.

On the 68020 you can use a subset of “PC Indirect with Index (base displacement)” for a 32-bit displacement. This is very wasteful to use by default if most programs have segments < 32K. However, compiler makers should provide the option of using an instruction that does not limit the branch to 32K if the user wants it, regardless of the overhead.

Two relate to data:

3. The size of global data

Global data referenced to A5 has a limit in MPW (1.0 and 2.0b1), which allows only 32K of for ALL static data, such as variables allocated at the outermost scope, string constants, etc. This is a severe limitation for moving mainframe programs, hopefully one to be fixed in the future.

4. The largest indexable size of an array

Arrays do not have to have a limit. This is a decision made by a compiler, and the easiest of the four to handle properly.

For example, MPW Pascal 2.0b1 allows you to declare large arrays (since Pascal requires fixed-size array declarations) and indexes such arrays slightly differently (sign-extending the index to a 32-bit long). Like any C compiler intended to compile programs designed for UNIX systems, MPW C assumes any array can be longer than 32K.

Because the last point is important and often misunderstood, I’ve enclosed some sample programs to demonstrate the point. The code generated for arrays of byte-sized elements would be somewhat different, since the index can be used directly, but the principle is the same.

{1}
The Pascal program

PROGRAM Arrays;
{$R-} {Small, clean code}
TYPE
 HugeArray = ARRAY[1..20000] OF LONGINT;
VAR
 SmallArray: ARRAY [1..100] OF LONGINT;{400 bytes}
 BigArray: ^HugeArray;    { 80,000 bytes }
 i: INTEGER;
BEGIN
 FOR i := 1 TO 100 DO
 SmallArray[i] := BigArray^[i];
END.

{2}
is compiled by MPW Pascal 2.0b1 to (edited DumpObj output):

 MOVE.W #1,$FE6A(A5)
 BRA.S  there
again:
 MOVE.W $FE6A(A5),D0 ; 16-bit array index
 ASL.W  #2,D0    ; 16-bit array displacement
 MOVEA.L$FE6C(A5),A0
 MOVE.W $FE6A(A5),D1 ; 16-bit array index
 EXT.L  D1; 32-bit array index
 ASL.L  #2,D1    ; 32-bit array displacement
 LEA    $FE6C(A5),A1 ; dereference pointer to array
 MOVE.L $FC(A0,D1.L),$00(A1,D0.W) 
 ;note 32-bit, 16-bit displacements
 ADDQ.W #1,$FE6A(A5)
there:  
 CMPI.W #100,$FE6A(A5)
 BLE.S  again

{3}

The C program

 typedef long HugeArray[20000];
 long SmallArray[100];
 HugeArray *BigArray;
 short i; 
 /* a register short in main() would be cleaner, 
 but not exactly the same as Pascal example */
 main()
 {    for (i=0; i< 100; i++)
 SmallArray[i] = (*BigArray)[i];
 }

{4}
is compiled by MPW C 2.0b2 to:

 CLR.W  i(A5)
again:
 MOVE.W i(A5),D0
 EXT.L  D0
 ASL.L  #2,D0
 LEA    SmallArray(A5),A0
 MOVEA.LBigArray(A5),A1
 MOVE.W i(A5),D1
 EXT.L  D1
 ASL.L  #2,D1
 MOVE.L (A1,D1.L),(A0,D0.L) 
 ; note both are 32-bit displacements
 ADDQ.W #1,i(A5)
 CMPI.W #100,i(A5)
 BLT  again

[Note: neither Lightspeed Pascal nor Lightspeed C will allow arrays over 32K. Obvously the future of the Macintosh II in the workstation market will be seriously limited by these restrictions of the softare development tools to support large compilations and data structures. We suggest that Apple and third party developers had better start taking steps to address these issues if the Macintosh II is to become a force in the workstation market. -Ed]

System 4.1 Compatibility

Apple has released the new “Universal” system file, version 4.1, along with Finder 5.5. This software is now shipping with the SE and Macintosh II and is Apple’s first attempt at creating a system that will bring together the Mac Plus, SE and Mac II with the same capabilities in as far as that is possible. As a result of the new software, we are beginning to get reports of what works and what doesn’t with the new system software. If you have additional reports, please communicate them in a letter to the Editor so we can continue to report on potential problems.

MacTerminal 2.0 Patch

Programs that were compiled using a low memory global called BasicGlob, no longer work with the new system. This includes MacTerminal, and programs created by the MegaMax C compiler. It seems this low memory global was assigned to Apple’s notorious MacBasic which never got past Microsoft’s eagle eye. It was originally used as a holder for a pointer to Basic's global variables so that Desk Accessories could have their own global variables. At least this is the use MegaMax made of it. This location has now been reclaimed for use with nested menus in the new system file, causing MacTerminal to crash eventually or upon exit to the Finder. The fix is to patch all references to BasicGlob to AppleScratch, a legitimate “spare part” for applications. Search for all instances (there are 4) of the hex low memory global 02B6 and change it to 0A78. This will allow MacTerminal to operate with system 4.1.

MegaMax C Patch

For any application built with the Megamax C compiler, patch your application as follows:

Find 2878 02B6 and change to 2878 0A80,

then find 21CC 02B6 and change to 21CC 0A80.

This is the same BasicGlob problem as MacTerminal, but uses a different scratch location. Contact MegaMax at (214) 987-4931 for a compiler upgrade if you are developing C programs. MegaMax also has a little utility program that makes this patch for you, which we will publish next month.

Ask Apple Tech Support

Chris Derossi, MacTutor contributing editor and former Editorial Board Member, will begin authoring an Ask Apple Tech Support column for MacTutor on programming questions for the Macintosh family. Chris is currently employed by Apple in it’s tech support department. This new column will be an “official” Apple column that will give the “official” Apple answers to toolbox, programming and system software questions. We are asking our readers to help the column get started by sending your “Ask Apple” questions to MacTutor, where they will be forwarded to Chris for use in his new column. Questions should be of a technical nature involving programming issues, preferably related to the Mac ROMS or system software. Save the fluff questions for MacUser.

Think Changes Offices

We have had reports that the phone number to Think Technologies is no longer in service and there is no new number. This has sent a chilling ripple among developers that perhaps Think, makers of the popular Lightspeed C and Pascal compilers, was doing out of business. We are delighted to report that this is not the case, that only the phones have been changed. The new number is 617-275-4800. New versions of Lightspeed C and Pascal are being prepared to support the new Inside Macintosh Volume 5 traps and equates.

LightSpeed C & Pascal for the Mac II

Philip Borenstein

Lightspeed Pascal is being updated to run on the Mac II and other 68020 machines as well as support the new traps and equates for the SE and Mac II machines. A major release of the Pascal compiler with new debugging features and full 68020 support is nearing completion for release this summer. In the meantime, developers who have a Mac II or are expecting their Mac II’s shortly, can call Think and receive a beta copy of Lightspeed Pascal 1.01. This version will run on the Mac II as well as on other 68020 Macs. It has been available to all registered Lightspeed Pascal users who ask for it since December 1986. A general upgrade will be available shortly.

Users who want to use 256K ROM stack-based traps right away can take advantage of Lightspeed Pascal’s inline feature. For example, if there is a trap Foo that returns an OSErr and takes two arguments, an integer and a Ptr, and its trap number is $A000, you woud write:

function Foo (i:integer; p:Ptr):OSErr;
inline $A000;

Lightspeed C owners can use the current version (2.01) on the Mac II. To get to the 256K ROM traps, they would need to declare the following:

pascal OSErr Foo () = 0xA000;

The C programmer is responsible for making sure that the arguments passed are the right size. The pascal directive ensures Pascal stack discipline.

The best way to use these features is to create a source file of 256K ROM trap routines and then add the file to your project. When Think releases the 256K ROM libraries, you can remove your file and add the library. Think is committed to providing the best development environment for the Macintosh and the best possible support for our customers. If there is anything I can help with, please let me know.

Copy To Mac SE Bug Fix

John Foster

The new 6.5 version of Copy To Mac includes a patch file that fixes some bugs in the new Platinum Mac Plus and SE ROMS. This bug causes the wrong tag information to be written to the disk, which makes undeleting files unreliable. The file, named CPS Tag Fix, also corrects another bug in the SE ROM that is causing the upper drive in the Mac SE to turn on and off unnecessarily. To use CPS Tag Fix, copy the file into the system folder of a hard disk or a startup disk. On the welcome to Mac screen, you get a note that the fix has been installed. These tags are a feature of the Mac that provides for more reliable recovery of deleted files and some damaged disks, but Apple has several times in the past changed their minds about supporting file tags. As a result of the SE bug, official support of file tags is currently “out of favor”. The following information is taken from a technical note supplied by Central Point Software with their new Copy To Mac version 6.5. [We think Apple needs to begin giving much more attention to making the file system more robust and recoverable from the disk crashes that plague us all. -Ed]

File Tags

All files are made up of 512K byte blocks on a volume. A tag is associated with each block on the disk describing which part of which file this block belongs to. The MacTools undelete files option reads the tag information from each block to help recover undeleted files. Tags written by a 512K un-enhanced Mac are correct. Tags written by a Mac 512KE or Mac Plus with 128K ROMS or a Mac SE are unreliable. This has prevented the MacTools and other recovery programs which rely on tags from working correctly. What makes the disk tags unreliable is a feature called the track cache found in the SE ROMS and newer Platinum 128K ROMS. The track cache, (see tech note 81) is different from the RAM cache found in the control panel. Whenever the Mac needs to read or write one or more blocks, on a 3.5 inch disk, the disk routines must first step the drive’s read / write head to the appropriate disk track and wait for the desired blocks on the track of the spinning disk to pass by the head. While it is waiting, other blocks on the track might pass by the disk head first; blocks which are not needed now, but might be requested later. In most cases the Mac has nothing else to do while waiting for the desired blocks so it reads the other blocks passing by into an area of RAM called the track cache. If an Application needs to read the other blocks, the disk routines will simply provide the blocks from the fast ram track cache rather than re-read them from disk. This generally improves disk access speed and efficiency. The track cache can store blocks from just one track at a time. Track caching can occour while the disk routines are waiting to read or write to a track. Here is how the track cache disturbes the file tags.

When a file is written to disk, the Mac file manager, places the tag values to be written into a special global tag location for use by the disk routines. The disk routines are designed to take the value stored at this global location and write them as the tags with each block. If while waiting for the desired blocks to pass by the read / write head, one or more other blocks pass by first, then the disk routines will read these blocks into the track cache. Unfortunatley, when a block is read into the cache, that block’s tag is also read into the same global tag location, overriding the previously correct tag values left by the file manager. When the desired block does pass by, the tags written to disk will be from this other block read previously rather than from the correct block now being written. Tags written to the disk may be wrong whenever the disk routines have an opportunity to cache a block BEFORE writing a block. CPS Tag Fix corrects this problem without affecting tag caching. When CPS Tag Fix is installed at system start-up, the tag values are written to a safe memory location allowing the tag values to be restored when the desired block passes by the read / write head. Unfortunately, tags are not supported on most hard disks. See tech note 94 and page two of tech note 96. To fix tags on existing disks, make sure CPS Tag Fix has been installed then copy all the files onto new inited disks from the Finder desktop. The copies made will then have the correct tags.

SE Upper Drive Bug

CPS Tag Fix also corrects the SE internal drive. Without the fix, the upper dirve runs slower and noisy. Try re-starting the Mac with a disk in the upper drive and you’ll see the difference. The upper drive makes twice as many noises in disk operations. The source of this problem lies in an SE routine in the ROM called JDISKSEL. This routine selects the desired drive. Sometimes this routine is called even though the proper drive is selected and spinning. But that is not a problem. However, the routine itself first assumes that the lower drive should be selected and actaully selects it! It then checks if the assumption was right, and if the upper driver should instead be selected, it then correctly selects that! But if the upper drive was already selected and spinning, this momentary de-select results in turning the upper drive motor off. Another part of the disk code, quickly notices the motor is now off and turns it back on again. This rapid motor on/off makes the additional noise similar to stepping the read write head from one track to the next. The disk code must wait another brief moment to make sure the disk is back up to speed before continuing. During normal disk operations, The JDISKSEL routine is called quite frequently, turning the upper drive off and on every time. The CPS Tag Fix file patches JDISKSEL so the upper drive is not deselected / reselected. Apple might provide their own fix to the SE upper drive in a future release of system software. [Is it in 4.1? We don’t think so. -Ed] CPS Tag Fix is designed to respect other system patches if it finds another patch already installed, it does not install it’s own patch so as not to produce a conflict. Contact Central Point Software at 503-244-5782 and request the Copy To Mac version 6.5.

Mousehole Remarks

Tom Pittman

The May 1987 issue of MacTutor contained several remarks by correspondents that can be answered better than they were:

Anthony Oresteen wants to generate text files where no line is greater than 68 characters. It’s not really hard to do on the Mac. The most obvious is, as he suggsted, to compose in MacWrite and save as text with carriage returns at line ends. Manually getting rid of blank lines between paragraphs is much less work than manually cutting each line. But even that is unnecessary. I believe the text editor QUED can be programmed to delete blank lines. If not, the editor MEDIT (version 1.3 is free, version 1.5 is $25 shareware from most BBS systems) certainly can. But why use two programs at all? I do exactly the same thing all the time in MEDIT: I just set the window width to the desired line length, using the mon-spaced Monaco font, then run a macro to cut all folder lines. A few seconds and the file is converted. The same macro also coverts curly quotes to the IBMish straight ones.

“Misteray” in the Mousehole report notes the existence of Fax add-on boards for the PC and speculates that the Mac II will allow these kinds of things on the Mac. All that is needed is a fax-compatible modem, which could be plugged into the serial port of any Mac. The CPU that does the data compression in the add-on boards is not as powerful as the Mac CPU. The trouble is that nobody wants to write the (not so complicated) software to do it. You can charge $1000 for a CPU + modem board; we all know that modems alone go for under $300. IBMers are being ripped off to the tune of $700. Slotted Macs have nothing to do with it.

The same author also had trouble with copying files from his RAM disk in Finder 5.3, to which the editor opined that the RAM disk was at fault. I have had similar problems with other Finders and no RAM disk. It has to do wwith the way the Finder handles hierarchical directories recursively. If memory is short, as it would be with a RAM disk installed, the Finder can get badly confused and sometimes even crashes. It’s a Finder problem.

BlockMove for Update Events

Fernando Salazar

Something in your May ’87 issue caught my eye. Two articles, the ABC column and Pascal Procedures, used CopyBits to transfer off-screen bitmpas to on-screen windows. Bob Gordon’s article uses CopyBits to manage Update events, while Gary Palmer’s article uses it to scale whole MacPaint images. Both cases seem to exceed the 3K limit suggested for CopyBits in Inside Mac. What’s the deal on this limit? Is there a way to determine how much is OK to copy? Programs like FullPaint seem to keep within the limit; when you paste into the scrapbook from FullPaoint, then from the scrapbook into MacDraw or CricketDraw, the pasteed bitmap appears as several objects about 3K in size. Paint Grabber, on the other hand, puts a single large bitmap onto the Clipboard. [CopyBits uses the stack, so limitations on CopyBits are tied to the available stack space. The suggestion of a 3K limit assumes a 6K stack space. If the application can guarantee the operation won’t take more than half the available stack space, then there is no limit. -Ed]

I have a program that uses off-screen drawing to reduce flicker in scrolling. It uses BlockMove instead of CopyBits, first to make an off-screen copy of the current Port, then to move the modified copy back on-screen. This type of code isn’t helpful for scaling an image, as is done in the MacPaint article, but for quick handling of update events, it should work fine.

{5}
Procedure OffScreenDraw;
var
 currPort:  GrafPtr;
 oldBits,tempBits: BitMap;
 aSize: Size;

Begin {save current port, create off-screen bitmap}
 GetPort(currPort);
 oldBits:=currPort^.portBits;
 tempBits:=oldBits;
 With tempBits do 
 aSize:=rowbytes * (bounds.bottom-bounds.top);
 tempBits.baseAddr:=NewPtr(aSize);
 {copy current port bitmap to new one}
 HideCursor;
 BlockMove(oldBits.baseAddr, tempBits.baseAddr, aSize);
 ShowCursor;
 {Set currPort to off-screen bitmap and start drawing }
 SetPortBits(tempBits);

 { Put a proc that draws to CurrPort here }

 { copy off screen bitmap to original}
 HideCursor;
 BlockMove(tempBits.baseAddr,oldBits.baseAddr,aSize);
 ShowCursor;
 SetPortBits(oldBits);
 DisposPtr(tempBits.baseAddr);
end;