copying/pasting images in MacOS X

[Gerry]

This is just out of curiosity.

I'm wondering how copying and pasting of images in MacOS X works.

I'm assuming that Cocoa applications put PDF data into the scrap when
copying image data.

And Carbon applications put PICT data into the scrap.


What happens when a Carbon application wants to paste an image copied
from a Cocoa application? Or vice versa?


Does this just not work? That would seem like a bad idea.

Or does the scrap manager somehow convert between these two formats?


I'm on an older Mac, so I'm unable to verify what actually happens.

And what about something like Gimp, which is neither Carbon nor Cocoa?
or is it?

I apologize for my ignorance ;)

--
[email]gbeggs@Canada.com[/email] [url]http://www3.mb.sympatico.ca/~gbeggs1/[/url]

[Tom Harrington]

In article <1g0ztxi.17vikm41pfs9m4N%gbeggs@Canada.com>,
[email]gbeggs@Canada.com[/email] (Gerry) wrote:

> This is just out of curiosity.
>
> I'm wondering how copying and pasting of images in MacOS X works.
>
> I'm assuming that Cocoa applications put PDF data into the scrap when
> copying image data.
>
> And Carbon applications put PICT data into the scrap.

Cocoa applications can put whatever kind of image they want onto the
clipboard. PDF's available if it's appropriate, but TIFF, etc, are also
readily available. Which format gets used is up to the developer. An
application can also declare that it's able to provide several formats
and then lazily provide just one of them, depending on the receiving
application's needs.

I'd presume Carbon has similar capabilities.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.4: Best cleanup yet, gets files other tools miss.
See [url]http://www.atomicbird.com/[/url]

[Gerry]

Tom Harrington <tph@pcisys.no.spam.dammit.net> wrote:

> I'd presume Carbon has similar capabilities.

Yes. But the standard format (at least pre-MacOS X) has always been
PICT.

There should be one standard format to copy/paste image data. Otherwise,
results are unpredictable.

Some applications will be able to accept scrap data from certain
applications but not from others.
This is sounding more and more like Unix, and not like the Mac ;)

--
[email]gbeggs@Canada.com[/email] [url]http://www3.mb.sympatico.ca/~gbeggs1/[/url]

[Tom Harrington]

In article <1g1102r.1ihjedh10antaaN%gbeggs@Canada.com>,
[email]gbeggs@Canada.com[/email] (Gerry) wrote:

> Tom Harrington <tph@pcisys.no.spam.dammit.net> wrote:
>

> > I'd presume Carbon has similar capabilities.

>
> Yes. But the standard format (at least pre-MacOS X) has always been
> PICT.
>
> There should be one standard format to copy/paste image data. Otherwise,
> results are unpredictable.

BS. If one application can provide TIFF data, and another application
can accept it, why should they be required to convert to PICT (or
indeed, to any other format) to make the transfer?

> Some applications will be able to accept scrap data from certain
> applications but not from others.

This has always been the case, though, hasn't it?

The Cocoa approach enables an application to say, at the time of copy,
"here's a list of several data formats I can provide; tell me which
one's needed and I'll supply it". When the paste occurs, the
originating application learns what format is needed and provides it.
The mismatch you predict only occurs if the two applications are
fundamentally unable to share data formats, and if that's the case,
enforcing a standard isn't going to help anything.

Again, I presume Carbon has similar capabilities.

> This is sounding more and more like Unix, and not like the Mac ;)

If "like the Mac" means apps are required to coerce data into
inappropriate formats for copy-and-paste to work, then "more like Unix"
is an improvement.

--
Tom "Tom" Harrington
Macaroni, Automated System Maintenance for Mac OS X.
Version 1.4: Best cleanup yet, gets files other tools miss.
See [url]http://www.atomicbird.com/[/url]

[Tom Dowdy]

In article <tph-0354AE.09410810092003@localhost>,
Tom Harrington <tph@pcisys.no.spam.dammit.net> wrote:

> In article <1g1102r.1ihjedh10antaaN%gbeggs@Canada.com>,
> [email]gbeggs@Canada.com[/email] (Gerry) wrote:
>

> > Tom Harrington <tph@pcisys.no.spam.dammit.net> wrote:
> >

> > > I'd presume Carbon has similar capabilities.

> >
> > Yes. But the standard format (at least pre-MacOS X) has always been
> > PICT.
> >
> > There should be one standard format to copy/paste image data. Otherwise,
> > results are unpredictable.

>
> BS. If one application can provide TIFF data, and another application
> can accept it, why should they be required to convert to PICT (or
> indeed, to any other format) to make the transfer?

Both the scrapbook/clipboard/pasteboard/drag and drop in both Carbon and
Cocoa provide mechanisms to allow multiple descriptions of given data
formats.

In addition, for all but the clipboard, these can be provided in a lazy
manner -- not actually populated until requested.

Also, PICT isn't a format really -- it's a container, and can within it
hold TIFF, JPEG, etc images (anything that can be described via
compression/decompression) in a lossless manner. So, it is perfectly
reasonable for applications that provide TIFF to also package as PICT as
one of the available data flavors.

QuickTime provides facilies for both loading this image data into a PICT
and also for "converting" it back out in a lossless manner (or actually
converting it if it needed to be).

> > Some applications will be able to accept scrap data from certain
> > applications but not from others.

>
> This has always been the case, though, hasn't it?

No. It has always been recommended that applications provide one or
both of 'TEXT' and 'PICT' in addition to other formats (ie, styled text,
TIFF, PNG, etc) for maximum ease of use by users.

Applications that fail to do this will work with *less* other
applications rather than more. In fact, it is exactly this problem that
causes a few rather large and rather visible Cocoa applications from a
rather large computer company to fail to be able to source image drags
into other applications.

[Simon Slavin]

In article <1g1102r.1ihjedh10antaaN%gbeggs@Canada.com>,
[email]gbeggs@Canada.com[/email] (Gerry) wrote:

>Tom Harrington <tph@pcisys.no.spam.dammit.net> wrote:
>

>> I'd presume Carbon has similar capabilities.

>
>Yes. But the standard format (at least pre-MacOS X) has always been
>PICT.
>
>There should be one standard format to copy/paste image data. Otherwise,
>results are unpredictable.

Erm, no. Because there are lots of different things, all
called images, and all with different abilities. For
instance, some can handle transparency and some can't;
some can handle positioning data expressed in floating-
point coordinates and some can't; some contain data
expressing how to represent the colours in different
colour-spaces and some don't; some can handle ways to
represent the same image at different resolutions and
some can't.

And some applications, which really care about incredible
detail in pictures, do different things when supplied with
pictures in different image formats whereas others which
handle pictures in a quick-and-dirty manner just always
ask for one format.

So the pasteboard system doesn't work the way you describe.
Instead, the application supplying the data can supply it
in any number of formats and the application which uses
the data can consult the list of available formats and pick
which one it likes best.

And that's why I can apparently paste a graphic containing
text into a well-written text-only application and get the
actual text out of it.

> This is sounding more and more
> like Unix, and not like the Mac ;)

No, it's flexible and does its best to use all available
data to do what the user wants. It's Mac-ish.

[Simon Slavin]

In article <1g139b1.4y1op3exzvimN%gbeggs@Canada.com>,
[email]gbeggs@Canada.com[/email] (Gerry) wrote:

>Tom Harrington <tph@pcisys.no.spam.dammit.net> wrote:
>

>> BS. If one application can provide TIFF data, and another application
>> can accept it, why should they be required to convert to PICT (or
>> indeed, to any other format) to make the transfer?

>
>Because only if there is one standard format can we assume that
>copy/pastes will work with all applications which support image data.

There is no one thing that is image data. Are you going to set
a new standard that you demand that everyone should keep to ?
Is your standard going to deal with all the huge number of things
that the different existing standards can handle ?

>Other formats can be provided in addition to the standard format for
>those applications which support them, but there should be a base format
>supported by all.
>
>Without a standard format, there could be any combination of formats
>provided. But unless another application decides to support at least one
>of those formats, it won't work (when it should).

Pretty much any application which copies or pastes images will
handle PICT format. Does that satisfy you ?

[Gerry]

<slavins@hearsay.demon.co.uk> wrote:

> Pretty much any application which copies or pastes images will
> handle PICT format. Does that satisfy you ?

This conversation has gone beyond what I had intended.
Yes, I realize there are different image formats which have different
capabilities.

However, on MacOS 9 (and earlier), PICT was the format used to
copy/paste any image which could be represented in the PICT format. This
covered 99% of the cases.

I think I can safely assume that Carbon applications will still put PICT
images into the scrap.

My question was that do Cocoa applications normally put PICT data into
the scrap when copying images (if the image can be represented as a
PICT)?

Since PDF is the "native" image format for MacOS X, I was thinking that
Cocoa applications would put PDF data into the scrap instead of PICT's,
which would cause unexpected incompatibilities between Carbon and Cocoa
applications.

--
[email]gbeggs@Canada.com[/email] [url]http://www3.mb.sympatico.ca/~gbeggs1/[/url]