Hyperion Entertainment Message Boards

@ 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.

This is ofcourse a good thing. Format has different meansing in different applicataions, even with similar meaning the 'style sheets' used in two docs are unlikely to be the same, causing the advanced user far more hasle than it saves for the lowlevel user. Have you ever looked at the straem of proprietry xml junk inserted into the clipboard in windows by Word? Then tried to deal with it when pasted into your webbrowser appliacation? Yes? then I rest my case (And Open Office posts a differenrt varaiation on the same junk)

Text and optionally character set is the most that should be passed as anyting else is meaningless.

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 storetext 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.

Although the FTXT format can support formatted text in it's specification, I think it's a mistake to assume that it was intended to be used that way within the clipboard. Whilst it doesn't explictly say anything either way, all the examples deal with posting ASCII not ANSI text.

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."

IFF FTXT as is stands is best left alone I think ANSI text is way short of suitable for what you describe.

It's perfectly acceptable and intended as far as I can see to post multiple blocks of IFF data to the same clipboard item, an apliaction wishing to post formatted text should probably post IFF FTXT for the unformatted version plsu some other suitable IFF FORM for the formatted version.

A web browser copying an image to the clipbaord might post the url as FTXT and the image as ILBM then the pasting app uses the appropriate form.

How Many apps use this I don't know, but its described in the RKM, at least in passing.

Wordworth does in fact do something similar although unfortunatly all it posts is a back reference to it's internal clipboard for it's own use.

The best format to post formatted text is probably appliacation specific, and thus should be posted in such a way, but ofcourse with documentation to allow other interested apps to make use of it.

tonyw wrote:There has been a groundswell of opinion in recent years that we should get away from the IFF "chunk" format of storing data. These days we are being encouraged to use XML. New Prefs editors are storing their data as XML, for instance.

XML is great for structured textual data (or numeric data as well) but not good for binary data.

Also it doesn't by itself give any compatabilty with other xml data, unless both sets of xml use the same DTD.

The clipboard needs to deal with TEXT, IMAGES and AUDIO at the very least so xml is a bad choice for that.

chris wrote: When are we going to be sharing the clipboard data with Linux and Windows?

There is at least one application on os4depot that does exactly that. (though only with windows).

Sharing clipboard data acroos a LAN with my different machines would be exceptional useful IMHO. But that's a fraction off topic.

trixie wrote:AmigaOS's clipboard uses the IFF FTXT format to exchange text between programs. This is simple and well-documented in the RKRM. However, in most (all?) applications, clipboard support is limited to the exchange of plain (unformatted) text. In the future, Amiga programs will want to do better.

To that end we need simpler IFF support like an updated IFF library that lets programmers save and retrieve data without the intricacies IFFParse.library. Something with functions like WriteText(font, fsize, style) or similar.

The use of control sequences is quite underdocumented. I haven't managed to find a code example of how to use them in IFF FTXT; neither have I found a list of control sequences that have been adopted for use in AmigaOS.

Documentation for OS4 is a big issue in general. A lot of documentation is available but needs to be found, organized and made easily available. For example, there is a document on the old Amiga Developer CD's that might provide some additional answers about control sequences. There is a file named "ftxt" in the directory Extras/IFF/Old_IFF_Packages/April_1987/DOCS/ on both of the Developer CDs.

OS devs, any word on this? Considering that IFF FTXT is probably going to stay as the format for clipboard text, perhaps we could do something about it now?

If so, the first thing to do would be to make copying and pasting formatted text work in OS4 programs and consoles. I just tried copying some bold & italic text from a shell window and then looked at the clip in Clipboards: with a Hex reader and see no binary data except a leading number that appears to be the length of the text.

Edit: Speaking of IFF, it would be nice if there were an OS4 registry of officially recognized IFF FORMS like the old one at http://amigan.1emu.net/reg/iff.html except with the exact definitions and descriptions.

To that end we need simpler IFF support like an updated IFF library that lets programmers save and retrieve data without the intricacies IFFParse.library. Something with functions like WriteText(font, fsize, style) or similar.

How is that remotely related to IFF? IFF can store any data not just text, and that goes for the ClipBoard too.

If so, the first thing to do would be to make copying and pasting formatted text work in OS4 programs and consoles. I just tried copying some bold & italic text from a shell window and then looked at the clip in Clipboards: with a Hex reader and see no binary data except a leading number that appears to be the length of the text.

I would hope you saw more than that,, the FORM and FTXT tags for instance. But you wil have the seen the text as plain text as no uses the formatting option of the FTXT FORM in the clipbaord. If you added it now it would break loads of stuff.

If you want formatted text it should be added as an additinal chunk or FORM of data. In additiona too the unformatted version.

Edit: Speaking of IFF, it would be nice if there were an OS4 registry of officially recognized IFF FORMS like the old one at http://amigan.1emu.net/reg/iff.html except with the exact definitions and descriptions.

It would indeed, although the defineitions might well be copyright there various owners, some may ot may not be available.

broadblues wrote:How is that remotely related to IFF? IFF can store any data not just text, and that goes for the ClipBoard too.

I probably used a bad name for my example function and I didn't make myself clear. Instead of using iffparse.library directly (which can get somewhat complicated), a simple-minded programmer like me would prefer library that has a set of functions for writing to an IFF file in a simpler way. In fact Maybe my example function should be something like IFF__WriteText_To_IFF_Buffer(text, font, style, charset) or IFF_WriteImage_To_IFF_Buffer() with appropriate arguments. Actually, textclip.library is a good start in achieving simplification for text clip reading and writing. The "ftxt" document has demo code for stripping "proper" FTXT to eliminate the control codes and extract the ASCII text but most (all?) programmers didn't use that information so including control codes in FTXT now is probably hopeless. If you read the "ftxt" doc you see that it was intended for "formatted text" though.

I would hope you saw more than that,, the FORM and FTXT tags for instance. But you wil have the seen the text as plain text as no uses the formatting option of the FTXT FORM in the clipbaord. If you added it now it would break loads of stuff.

True; which is why I agree with your next statement.

If you want formatted text it should be added as an additinal chunk or FORM of data. In additiona too the unformatted version.

Yes and if you look at a PageStream clip with a Hex editor, that's exactly what the author did. In fact I just noticed that in the Dev CD there is a "WORD" form submitted by Prowrite for use with word processing documents.

It would indeed, although the defineitions might well be copyright there various owners, some may ot may not be available.

Actually, some of the old ones are available (with no copyright notices) on the developer CD's. There is an old IFF registry in the Extras/IFF/IFF_FORMS directory of the developer CDs. It could be updated as a starting point for a new OS4 IFF registry.

In the case of adding simple formatting to FTXT, I think some new CHUNKS would be the solution. In fact, new functions for reading and writing FTXT with the new chunks could be added to the textclip.library for simple minded people like me

trixie wrote:OS devs, any word on this? Considering that IFF FTXT is probably going to stay as the format for clipboard text, perhaps we could do something about it now?

I'm not an OS dev but I think broadblues is on the right track. The "ftxt" documentation states "New optional property chunks may be defined in the future to store additional formatting information." and that is probably the best approach. It would also be nice to add functions to textclip.library to read and write the formatted text. Of course, people like me might wonder why (complain?) formatted text can't be cut/copied/pasted from a console or displayed with datatypes. Once additional chunks are defined, it would be a good idea to at least make OS text oriented programs and gadgets capable of using the new chunks. If you define the chunks but the OS doesn't use them, it's unlikely that 3rd party programs will either. I would guess that some MUI and Reaction classes would need significant updates to make use of the new formatting chunks. Defining them would be a start though.

Ah-ha, found one!

When copying AmigaGuide files to the clipboard, they retain their formatting. The codes seem to be using the ESC[ sequence rather than the 0x9b that all the documentation suggests FTXT should be using. A "MultiView clipboard" shows the text formatted correctly. Unfortunately, NotePad predictably shows things like [9m embedded into the text. CSI code 0x9b didn't work with MultiView in some brief tests.