Paste image from clipboard into Keynote

The 'short' answer

... is that different apps copy formatted text to the clipboard in different ways, and different apps support pasting from different formats. Typically you'll get some kind of 'plain text' format, as well as maybe HTML or RTF formatted text in the clipboard, and it's up to the pasting app to choose which it likes best.

Keynote 6.1 definitely supports some kind(s) of formatted text pasting, as I can get this to work with Safari. But it doesn't seem to work with Firefox or Chrome (at the time of writing). From a bit of testing, it seems the Apple apps all play nicely together (no surprise there), and a few others will copy/paste to/from the Apple apps too (including Microsoft Office products). Unfortunately when you copy from Chrome, you only get plain text & HTML-formatted text copied to the clipboard, so it would appear Apple's iWork apps don't support pasting HTML formatted text.

So if copy/paste doesn't include formatting, you can either:

• Try a different browser to copy from, such as Safari; or
• Find an intermediate app to paste into (which 'speaks' both HTML formatting and can re-copy into a format Keynote/etc understand), such as Apple's own TextEdit.app

Surprisingly, Apple's own TextEdit.app will happily paste formatted text from Chrome, and it can be re-copied to the clipboard and pasted with formatting into Keynote/Pages/etc.

Depending on your point of view, this may seem a limitation (or fault) in Chrome/Firefox or in Pages/Keynote/etc, but in the end they simply don't speak the same formatting languages (at present).

I'd encourage anyone experiencing this to send feedback to the developers on both 'sides' in the hope of getting this fixed—either with Chrome/Firefox supporting RTF/RTFD copying (or whatever is most standard/appropriate beyond HTML), or by Apple's iWork apps supporting the pasting of HTML content.

More than you want to know about copying to the clipboard

When you copy some text to the clipboard, depending on the application, it may get copied in a few formats. You can see these using Apple's Clipboard Viewer application (requires building in Xcode).

For example, copying from Google Chrome, the clipboard gets populated with four separate copies of the information I copied—two plain text (public.utf8-plain-text, NSStringPboardType), and two HTML formatted (public.html, Apple HTML pasteboard type).

Copying from other apps gives various combinations of format types, with some other common ones being 'TEXT' (CorePastboardFlavorType), com.apple.traditional-mac-plain-text, Apple PDF pasteboard type, Apple PICT pasteboard type, public.rtf, NeXT Rich Text Format v1.0 pasteboard type, NeXT RTFD pasteboard type, com.apple.flat-rtfd, com.apple.iWork.TSPNativeData, com.adobe.pdf, com.adobe.indesign-import-ustl, and so on...

As you can see there are a variety of plain text formats (with various encodings like UTF8/UTF16), RTF types, PDF and Adobe types, image types. There's also a bunch of metadata types that describe the application that copied the data (e.g. com.apple.iWork.TSPNativeMetadata), or the features of the copied text (e.g. com.apple.iWork.TSPDescription), and what appear to be separated text and style data (ustl and TEXT as CorePasteboardFlavorTypes, and their com.adobe.indesign-import- equivalents).

I don't know any way of seeing which format types are supported by which applications for pasting, but using the Clipboard Viewer you can quickly see which format types are generated on copying.

Stdout in this case is line-buffered and is 1024 bytes which is causing the output truncation on the display. When you paste from the clipboard the non-printable New-Line (EOL) characters at the end of each line are simply counted as another character on the line as far as the buffer count is concerned. The reason the math doesn’t add up for where the truncation happens that @miken32 was trying to calculate, is because you are not counting the New-Line characters.

If you cat the test file using a –e option you can see the non printable EOL characters as $, including them in the math should add up.

$ cat -e test
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$
1234567890,1234567890,1234567890,1234567890,1234567890,1234567890$

You can get around filling the line buffer with pasted bytes if you specify your own end-of-file (EOF) marker to the cat command. This way when the cat command encounters the EOL characters it will reset the line buffer at the beginning of each new line instead of just counting them as another byte in a continuous stream because the cat command is parsing each new line looking for the EOF string on a line by itself to know when to exit.

You can do something like this :

cat << EOF > test

The stdin redirect (<< EOF) tells cat to keep printing until it encounters input matching the specified end-of-file characters on a new line by themselves. This way stdout will then print every pasted printable character line by line, the drawback is that you get a “>" character in the output at the start of each new line.

$ cat << EOF > test
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> 1234567890,1234567890,1234567890,1234567890,1234567890,1234567890
> EOF

The end-of-file marker is typed literally as the characters E, O, F, after your paste and can be anything you like. Also the EOF characters, and the > characters are not included in the redirected output sent to the file. Typing the letters as EOF is just symbolic and can be anything you like, XXX for example, you just have to be certain that what ever EOF marker you specify does not appear in the paste buffer.

For the record, you can still use ^D as the EOF marker when using stdin, even though you specify something else. The use of the EOF string is an old school scripting convention for delimiting a block of text to redirect from within the script.

Hope this helps.