Path: utzoo!mnetor!uunet!husc6!hao!ames!oliveb!pyramid!voder!apple!holt
From: holt@apple.UUCP (Bayles Holt)
Newsgroups: comp.sys.mac
Subject: Re: Screen Dumping to a LaserWriter
Message-ID: <7338@apple.UUCP>
Date: 6 Feb 88 01:56:38 GMT
References: <3956@husc6.harvard.edu> <174400099@uxc.cso.uiuc.edu>
Reply-To: holt@apple.UUCP (Bayles Holt)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 32

>>The recommended way of printing screen dumps is to execute an FKEY #3
>>(which saves the screen to a file) then printing the file like any other
>>bitmap file.  This is not only cleaner, its easier and is just as fast as
>                                ^^^^^^^      ^^^^^^        ^^^^^^^^^^^^
>>the FKEY #4.
> 
>Cleaner and easier and just as fast for who?  Apple System ...

Your point is well taken and I agree with it.  When I said it was simpler
to do an FKEY 3 I was referring to the application developer as the
client because it is better for her to do the printing by calling the
high level driver rather then simply executing a low level control
call.  But that isn't your concern.  Perhaps I misspoke on this aspect.
It is true, however, that the more correct way for the FKEY code to
implement the print feature is to print via the high level print
driver essentially duplicating the FKEY-3-then-print sequence and I'm
not sure if that will ever happen because after all the FKEY stuff
is not supposed to be an application.  Whats it doing printing for anyway?

As far as print software is concerned, we will still support the feature
for anyone who wants to program the process correctly, but we are
definitely going to phase out the low level call through which
FKEYs currently implements that feature.  The reason: it just doesn't
work right.  With background printing around the corner for all printers
we cannot continue to support the low-level driver the way it stands,
and it's the low-level driver through which the FKEY stuff does
its printing.

--Bayles
holt@apple.UUCP

:wq