Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!ncsuvx!mcnc!thorin!unc!steele
From: steele@unc.cs.unc.edu (Oliver Steele)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Spooling a PICT2
Message-ID: <2651@thorin.cs.unc.edu>
Date: 11 May 88 03:38:01 GMT
References: <2620@thorin.cs.unc.edu> <2788@polya.STANFORD.EDU>
Sender: news@thorin.cs.unc.edu
Reply-To: steele@unc.UUCP (Oliver Steele)
Organization: University Of North Carolina, Chapel Hill
Lines: 54

kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes:
>In article <2620@thorin.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes:
>
>>      (LSC bug:  a CGrafPort's grafProcs is defined as a QDProcsPtr
>>instead of a CQDProcsPtr.)
>
>This is because the first routines in a CQDProcs list are identical to the
>routines in a QDProcs list, and if you are only going to change, e.g. 
>TextProc, you don't have to check the Graf type or Ptr type (Apple seems to
>do this lots of places, not just here).

I don't see that this can work.  You're always going to need to put a
pointer to a CQDProcs in a CGrafPort's grafProcs, and not a pointer to a
QDProcs, because Quickdraw can't tell the size of the structure the
grafProcs is pointing to.  A QDProcs doesn't have room for the opcodeProc
and newProcs, so Color Quickdraw will jump to a random address if you
use a QDProcs' address here and it runs across a need for these.

The other way around works:  you can always allocate a CQDProcs and then
call SetStdProcs on a pre-II, GetStdCProcs on a color machine, and put
the address of your modified CQDProcs in your port.  But it seems that it's
NEVER all right to use a QDProcsPtr in a CGrafPort, so why declare it that
way?

On to better things:

>>I need to save a color bitmap as a PICT file.  Here's what I've tried:
[trials deleted, but basically my colors get munged]

>To get back to the original problem:  Why not open a NEW CGrafPort, with
>NO storage for the PixMap (portRect = (0,0,0,0)), and spool to that.  It
>works, and gains back the space you had allocated to the PixMap.  I think
>that if this is an Offscreen GrafPort, the color table will be saved to
>the spool file, since it is not the same as the source color table (you may
>have to twiddle the CLUT ctSeed in the Offscreen port to convince QuickDraw
>this is the case).

Thank you for the suggestion; it really looked like it ought to work.  It
gets me the same results as copying to the on-screen CGrafPort, however:
if I copy in bands, the color in the saved PICT is right; if I copy the
whole Rect at once (and Rect can be as small as 100x100 for this effect
to hold; I haven't yet tried to find the boundary), color gets munged.
And this is true even for a new ctSeed.  (Don't forget HandToHand when
you want a copy of a color table!)

I'll tell y'all (yes, I'm Southern) when I solve this.

 ---------------------------------------------------------------------------
 Oliver Steele					  ...!decnet!mcnc!unc!steele
 UNC-CH							   steele@cs.unc.edu

 "The screen is a window through which one sees a virtual world.  The
  challenge is to make that world look real, act real, sound real,
  feel real."		-- Ivan Sutherland, 1965