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