Clipboard support (in SDL)

[rakslice]

In B2/SS on Linux using SDL, at the moment it seems that there is just no clipboard support at all.

When building on Mac it has its own specific clipboard implementation that gets used, and it has the ability to use the PICT writer in pict.c to bring image data from outside into the emulated mac, and it looks like there is some facility for bringing whatever types that can just come straight across to the host pasteboard on Mac OS X as-is.

Other than that the only clipboard support on POSIX is for X11 but isn't used if you're building for SDL. (I can't tell if this is disabled on purpose or if it's an oversight, but I remember there being some issue with init order if you're using both X11 and SDL).

SDL itself has some clipboard APIs; in 2 this is just for text, which would still be useful.

It seems like they're trying to make this fully featured custom data type clipboard support in 3.

Make a new clipboard support implementation for this.

[rakslice]

I got a full plain text clipboard implementation working in Linux using SDL's iconv conversion with the "MACINTOSH" character set and it appears to work fine.

On Windows if there is a native Windows clipboard implementation that works it probably makes sense to just continue using that.

Obviously modern MacOS will keep on using its more specialized, better featured implementation.

I started down the road of implementing the inbound image support with PICT conversion for SDL 3, and got it basically working, but I found it to be unstable, where the system often crashes after putting a converted PICT on the clipboard.

With several test examples that crash, I found that it works fine if I force the RLE compression part of the PICT creation to not compress (that is, to create an RLE representation where all bytes are in literal sections and no match sections ["runs"] are used -- this is only normally used if the compression finds, for a given row of pixels of the image, that the actual RLE compressed version would be longer than the "not compressed" version would be.)

This suggests that the RLE compression code may be bad. However on further detailed testing of the specific rows that compression of leads to a crash in examples that crash, the RLE representations are correct -- I can verify that if I decompress them the result matches the original.

So I don't think there is actually a problem with the RLE compression code itself -- my hunch is that there is subsequent data corruption happening to the RLE compressed data afterward, and the nature of the "uncompressed" version (where the majority of the bytes are just pixels of image that any bit errors in would just go to the screen and nowhere else -- and don't functionally affect the decompression process) means it is just more robust to this corruption.

[rakslice]

Right now I'm just assuming it is appropriate to use and expect text in the "MACINTOSH" iconv charset in text in the emulated mac clipboard, and text in the "UTF-8" iconv charset with the host clipboard (using the SDL text clipboard functions which do not make any mention of character set that would tell you either way what to do). At least these charset names are constants that are easy to locate and change; I think we can cross the bridge of making these prefs when a use case for that is ever found.

Edit: No, the SDL 2 and 3 SDL_GetClipboardText and SDL_SetClipboardText explicitly say UTF-8 in the main description.

[rakslice]

From a discussion (https://discourse.libsdl.org/t/bug-iconv-utf-8-decoder/16904/6) the SDL iconv functions are sometimes not really iconv but an internal fallback, but from a look at the fallback (https://github.com/libsdl-org/SDL/blob/main/src/stdlib/SDL_iconv.c) it doesn't have "MACINTOSH" so I'm getting something more substantial than that.

[rakslice]

Evidently from testing, "MACINTOSH" has the extended "Standard Roman" version from https://dev.os9.ca/techpubs/mac/Text/Text-30.html#HEADING30-9

[rakslice]

Behaviour note: the iconv "MACINTOSH" character set reflects mac "Standard Roman" where possible, and I've had no problems with it.

However there are a couple of situations where the actual symbol shown doesn't reflect what "Standard Roman" says, and copying and pasting text with them will produce something different, in the same way that copying and pasting them as text in an unstyled context on a real Mac would do something unexpected:

1. System font control-codes

In classic mac system fonts like Charcoal and Chicago, there are additional printable symbols for the ASCII control codes, mostly font-icon style symbols for system use like the cmd and option icons, backward and forward delete symbols, etc.

You can type these here with control-letter combinations, and it produces character codes decimal 1 through 26 for Ctrl-A through Ctrl-Z (and which the left two columns of the "Standard Roman" table shows only the ASCII control code abbreviation meanings for.)

In most classic mac fonts, all the control characters have just the standard box placeholder symbol.

In most POSIX situations, the graphical representation of control characters is some kind of placeholder (commonly Unicode placeholder box with character number as 4 hex digits, or diagonal placeholders with the ASCII control code abbreviation.)

2. Symbol fonts

Symbol fonts use non-standard characters for all character codes, and obviously copying and pasting between individual symbol fonts and normal fonts will give different symbols.

[rakslice]

Likewise there is a conceptually similar problem with additional character set support in the classic mac:

When you have a language kit installed in MacOS 7-8 and additional character sets are in use, maybe several character sets at once in the same document, the font selection of any particular text acts as a surrogate for a character set designation -- partly by indicating what Mac OS calls a script, and the functionality present in the specific script implementation having whatever decoding behaviour is needed to handle the text byte data indicated for that script, and partly because what glyphs the font has for different character byte sequences in the script system intrinsically defines a character set.
https://dev.os9.ca/techpubs/mac/Text/Text-362.html

The clipboard/scrap functionality seems to have no special handling of different scripts at all. This means that in a styled text scrap, the font information on different regions of the text effectively acts as metadata indicating the character sets of different parts of the text character byte data. However in the unstyled text clipboard (fourcc 'TEXT') it's just all the characters in whatever encodings with no metadata indicating the character sets of any of it.

[rakslice]

When it comes to fonts being character-set-specific, it really poses two problems for passing around the modern idea of unstyled text:

• Taking text out, we would need to use the styled text, so we can find the regions that use different fonts, and we would need to do additional API calls to get the scripts associated with those fonts, and have prior knowledge of the encodings that would be in use for different script values.

• Putting text in, we would need to supply styled text; so we have to have the previous stuff in reverse, but besides that we are also specifying a style so we have to somehow come up with reasonable default parameters, including, even if we have already narrowed the font options to the ones for the right script, an actual specific default font pick.