I seem to have found it, it's in the RKRM Devices manual, Chapter 4 (Console device). It lists the ANSI control sequences for writing into the console window, and it looks like the list includes the CSI sequences the IFF specification refers to.
@ whoever is interested
I've done a bit of research, and I'll summarize my findings and opinions so that we have a point of departure:
1. Amiga applications (word processors, DTP programs, web browsers) never felt the need to support formatted text in clipboard data exchanges. They only cared about copying/pasting formatted text within the program: they stored plain text in the public clipboard and used an internal, proprietary mechanism to retain the formatting info. But you cannot copy a formatted text from WordWorth and paste it in PageStream (or vice-versa): the formatting will be gone.
2. What I am trying to say here in this thread is that such a feature (= inter-application formatted text exchange) would be nice to have - even more so in an age of the Internet, when there's so much text accessible from the browser. At the same time, I'm saying that such a feature can be introduced without changing the inner workings of the Amiga clipboard. The clipboard uses the IFF FTXT format to store text data, and the IFF specification (1985, updated 1988) quite clearly says that the FTXT format is meant to store
text that has explicit formatting information (or “looks”) such as font family and size, typeface, etc. /.../ Character looks are stored as embedded control sequences within CHRS chunks.
3. Unfortunately, the specification admits being somewhat incomplete on this:
This document specifies which class of control sequences to use: the CSI group. This document does not yet specify their meanings, e.g., which one means “turn on italic face”. Consult ISO/ANSI.
Referring to the ISO/ANSI control codes list, we'll find that there indeed is a CSI sequence called SGR (Select Graphic Rendition) for text properties. About three dozen optional parameters are specified for SGR. Of these, the above-mentioned RKRM Chaper 4 specifies seventeen parameters that are relevant to the console output. These includes parameters like "italic on", "underline off" etc.
4. The IFF FTXT specification also introduces the optional property chunk FONS, the font specifier, which
assigns a font to a numbered “font register” so it can be referenced by number within subsequent CHRS chunks. /.../ The font specifier gives both a name and a description for the font so the recipient program can do font substitution. By default, CHRS text uses font 1 until it selects another font.
Although the IFF specification does not mention how
font selection should be done for the text chunks, the ISO/ANSI control codes offer a logical solution. Indeed, the SGR sequence has parameters 10-19 to select from ten pre-defined fonts. This of course introduces an inherent limitation: only ten FONS chunks would be meaningful within an IFF FTXT file. But I don't see that as a major drawback. What represents a bigger problem is that neither the FONS data structure, neither the ISO/ANSI control sequence codes offer a parameter for specifying text size.
5. To sum up: in order to implement inter-application formatted-text exchange through the Amiga clipboard, we have most things already in place. The clipboard uses the IFF FTXT format, and the format specification does allow storing text properties: though the CSI sequences and the FONS chunk. Further, the specification clearly says that "new optional property chunks may be defined in the future to store additional formatting information."
What will need to be resolved is this:
- IFF FTXT does not support storing text size.
- If application programmers ever start using formatted text as per the FTXT specification, other programmers can no longer assume the clipboard to only include plain text data. Therefore, they'll need to implement proper control-code stripping (again, as per the FTXT specification) in their clipboard handling routines. (Let's note here that the assumption of the clipboard only including plain text has always been wrong and illegal.)
EDIT: Of course (taking into account that 1/ Commodore or EA can no longer update the IFF FTXT format for our needs, and 2/ formatted text has never really been used for clipboard data exchange on the Amiga), we could get rid of the entire CSI voodoo (which doesn't look very convenient anyway) and take a completely different approach. I think now that Hyperion has rights to the RKRM documentation and can update it for OS4, they can also update the IFF FTXT standard to something that would be more useful. To maintain maximum compatibility with older software (and to ease the life of developers), the best solution would be to separate the text from its formatting. What I mean: the CHRS chunk would only contain plain text, and a special chunk preceding or following the CHRS would contain respective formatting description. This way any application could store formatted text in the clipboard: applications not supporting/not interested in the formatting would read plain text data from the CHRS; and applications that do support formatted text would read from the formatting-description chunk.
I'd like to hear other developers' opinions on this.