This seems at odds with your parallel response suggesting the best
real world solution is probably for the developer to create a 32
bit helper app to do essentially the same thing. Also a 32 bit
compatibility process wouldn't have to be spawned until it was
needed, in which case you're paying the 32 bit framework penalty in
any case. From my point of view it doesn't matter if the
application is doing it with a helper app or the system is doing it
with a compatibility process. The penalty is still there and in
the clipboard case being discussed, there shouldn't be a penalty
anyway since apparently there's a 32 bit app running to place the
data on the clipboard in the first place.
Software could obtain PICT data over the network or from a file to
place on the clipboard without having any knowledge of contents
beyond data type. No 32-bit process running on the machine, but PICT
data on the clipboard, which you will then need to load 32-bit
frameworks to parse.
I agree it's possible, it just doesn't seem likely to be the common
case.
Here's a thought. We already have a mechanism in place to convert a
legacy graphics format for use in CoreGraphics (and it's even
supported in 64 bit mode). How about a PICT converter similar to the
CGPSConverter? It seems reasonable to expect PICT to get similar
treatment to PostScript.
Nick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
