December 93 - MACINTOSH Q & A
MACINTOSH Q & A
Macintosh Developer Technical Support
Q I want to write an application that can open incoming PowerTalk letters automatically. How can my PowerTalk-savvy application access the letters stored in
the in-tray?
A Currently, there are only two ways of accessing in-tray letters from your application. The most common method is to receive an open document ('odoc') Apple
event when a letter is opened from the Finder. In addition, calling SMPGetNextLetter
allows you to open letters from your application. It isn't possible, however, for your
application to access the in-tray from Standard File or to automatically open
arbitrary letters without user intervention.
Q When I open a letter in my PowerTalk-savvy application, I can obtain FSSpec records referencing folders or files enclosed in the letter, but the files don't appear to
be copied to my hard drive. Where do these files reside on my system?
A PowerTalk maintains an external file system for enclosures of letters. If you closely examine the FSSpec records returned to you, you'll see that the enclosed files
and folders reside on this external file system, named "Mail Enclosures." This is a
read-only file system, and the enclosures are available only while the letter is open.
Therefore, these FSSpecs should be used only to copy the enclosed items to your local
disk, and all references to them should be discarded by the time you call
SMPDisposeMailer.
Q When I call FrontWindow from within a VBL task, my system occasionally freezes at this call. Is there any chance that it moves memory?
A No, but FrontWindow is not reentrant. It's been patched out since MultiFinder, and ought to be on the list of routines that shouldn't be called at interrupt time. You'll have
to come up with another method of getting the front window from your VBL task. You
may want to keep a shadow copy of your application's window list in your application
global area where your VBL task can get to it.
Q We want a general extension for all PAP-capable printer drivers, to allow for user authentication at print time. It would conduct a user authentication dialog with a
spooler on the order of the one described in Chapter 14, "Print Spooling
Architecture," of Inside AppleTalk, Second Edition. Is it possible to do this in the
QuickDraw GX printing architecture? Would we do anything different for
PostScript-savvy print spoolers to insert the right document-structuring comments?
A For spoolers that are PostScript-savvy, you can override the message GXPostScriptDoDocumentHeader from a printing extension and insert your password
information in the PostScript header at that point, including password, user name, and
so on. When your spooler receives the job, it can check this data and see if it denotes a
valid user. By overriding this message you'll work with any PostScript driver, as long
as your spooler supports it. (You're actually talking only to your spooler, not to the
different drivers.)
For the authentication, you'll need to override GXOpenConnection to get the user's
name and password, since that's when you actually try to connect to the device or
spooler. You could use cool alerts (status dialogs) to get the information from the user
at that time. Be sure not to put up a "Type in your password, please" dialog except at
device communication time. At other times, the user won't be trying to connect to the
device and shouldn't need to provide authentication.
Q We plan to convert all our QuickDraw objects to QuickDraw GX objects when we print, then use a QuickDraw GX printing loop to print our objects. We print bitmaps at
the printer's maximum resolution, through PrGeneral. How do we print bitmaps at the
printer's maximum resolution in QuickDraw GX? How do we find the printer's
maximum resolution?
A To print bitmaps at the printer's maximum resolution in QuickDraw GX, create the bitmaps at the desired resolution (like 300 dpi) and then put a transform on the shape
to scale it by 72 divided by the bitmap's resolution. This method makes the bitmap
show up with the correct dimensions, whether it's drawn on a 72-dpi screen or a
300-dpi printer. And, on the 300-dpi printer, the bitmap will not be scaled at all --
it will render at 300 dpi. This works because, before drawing, the shape's scaling is
multiplied by the device's resolution divided by 72, to convert the shape to device
resolution.
To find a printer's maximum resolution, use the calls to get the information from the
printer's view device list (get the printer from the job via GXGetJobPrinter), pick
the highest-resolution printing device, and voilà!
Q My application won't print to a StyleWriter II although it works fine on all other printers, including the original StyleWriter. Can you give me any suggestions? What's
different about the StyleWriter II?
A The StyleWriter II driver is a member of the "GrayShare" driver family, with new features such as support for grayscale printing (if Color QuickDraw is available) and
printer sharing over the network. Its internal architecture is very different from
previous printer drivers. In spite of thorough compatibility testing, some problems
have shown up since the first release. In many cases, the driver revealed weaknesses
in the applications themselves; for some other problems, a solution will be
incorporated in the next release of the driver. Here are some identified problem areas
with GrayShare drivers (note that these don't necessarily represent bugs in the
drivers, but are differences in the system's configuration at print time):
• GrayShare drivers handle memory differently. For example, if an
application has a dereferenced handle to an unlocked block while doing a
CopyBits into the printing port, this may work fine on other printer drivers,
but the block is likely to move with a GrayShare driver and the results are
unpredictable.
• GrayShare drivers maintain their own A5 world internally. If an
application installs a growZone proc and forgets to set up its own A5 in the
growZone proc -- ignoring the Macintosh Technical Note "Register A5 Within
GrowZone Functions" (Memory 1) -- the growZone proc may get called with a
GrayShare driver's A5, which obviously is bad for the survival of both the
application and the printer driver.
• GrayShare drivers call the pIdleProc (in the job subrecord of the print
record) more often than other printer drivers; in particular, it may be called
during execution of PrOpenDoc. If an application reloads a previously used
print record containing an old (now invalid) pointer to a pIdleProc and doesn't
update the pIdleProc field before calling PrOpenDoc, disaster is very likely.
Note that Macintosh Technical Note "pIdle Proc (or how to let users know
what's going on during print time...)" (Printing 22) recommends installing
your pIdleProc before PrOpenDoc.
• Like most other QuickDraw printer drivers, GrayShare drivers use
algorithms built into QuickDraw for rasterizing picture elements like ovals
and arcs, but not necessarily with the same sequence of coordinate
transformations. Because of the 360 dpi resolution, internal computations
with the transformed coordinates may hit the 16-bit integer limitation of
QuickDraw and reveal bugs in the old QuickDraw routines that have remained
hidden until now.
• Some GrayShare drivers (like the StyleWriter II driver, version 1.0)
contain STR# resources with positive ID numbers that may conflict with
STR# resources in an application. This will be fixed in the next release of the
drivers.
• Under certain circumstances, GrayShare drivers seem to have trouble
with the PmForeColor call. This is under investigation and will be fixed.
Q We've been manually writing 'PAPA', 'STR ', and 'alis' resources in the System file and in the LaserWriter driver to change printers without using the Chooser. This
method sometimes causes errors with LaserWriter 8. What do we need to do?
A LaserWriter 8 needs to know more about the printer than its AppleTalk name -- it also has to have a PostScript printer description (PPD) file for that printer, parsed
and ready to be used. Since there's so little memory available in applications like the
Finder during printing, the parsing is done at Chooser time, not at print time.
Apple has always said "We can't guarantee that you can change printers behind the
Chooser's back," and with LaserWriter 8 this is true. If the driver has parsed a PPD
file and has it ready, things should work OK, but everything must have been manually