[RFC] New IFF FTXT chunk STYL

[chris]

(1) I've devised a chunk for changing font styles in IFF FTXT files. The existing infrastructure for styles in FTXT is barely supported anywhere and filtering out the codes does not happen either (even in OS included applications such as Notepad). There is no mechanism provided for embedding style information in FTXT UTF8 chunks. This partly follows on from http://forum.hyperion-entertainment.biz ... f=26&t=979

The suggested chunk looks like this:

struct styl {
UBYTE font; /* font ID specified in earlier FONS chunk */
UBYTE style; /* FSB_#? defines from graphics/text.h */
UBYTE pad[2]; /* reserved for future use */
ULONG size; /* font point size */
ULONG fg_colour; /* foreground colour ARGB */
ULONG bg_colour; /* background colour ARGB */
}

(2) On a related point, I don't actually like the UTF8 chunk, as it relies on the application ignoring another chunk if this one is found. I know of no other chunk that does this and it makes it more difficult to support. I'm not sure if changing the FORM type is a better alternative. Discussion welcome.

[trixie]

@chris

I've devised a chunk for changing font styles in IFF FTXT files. The existing infrastructure for styles in FTXT is barely supported anywhere

I'm all for this kind of standardization - the original CSI code-based support for text styles in IFF-FTXT is awkward, and was never used anyway (so there's no risk of breaking compatibility). Assuming that the existing FONS chunk cannot be extended to include style information, a new property chunk looks like the best solution.

I don't actually like the UTF8 chunk, as it relies on the application ignoring another chunk if this one is found

I've never used or heard of the UTF8 chunk - does it contain UTF-encoded character data, thus replacing the CHRS chunk?

[chris]

@chris

Assuming that the existing FONS chunk cannot be extended to include style information, a new property chunk looks like the best solution.

There is one pad byte in FONS. Style could be put in there, but you would still need font size and colour information somewhere.

I've never used or heard of the UTF8 chunk - does it contain UTF-encoded character data, thus replacing the CHRS chunk?

Yes. See here: http://wiki.amigaos.net/index.php/UTF8_ ... icode_Text
It's only used on MorphOS at the moment, although I've added support in newer NetSurf builds as it is slightly better than manually switching between local charset and UTF-8 CHRS (although, actually it supports both options). Scanning through for UTF8 chunks prior to extracting data from either CHRS or UTF8 chunks is not at all friendly through iffparse.library, so I can't see it catching on.

Abandoning FTXT for a different FORM (let's call it UTXT for the sake of argument) that specifies CHRS blocks as UTF-8 might be a better solution, although I'm not sure it will solve the programming issue. The IFF specification is quite happy with "this chunk supercedes that chunk" but iffparse.library doesn't appear to have a mechanism to directly support it, so that is probably the best fix.

[salass00]

Yes. See here: http://wiki.amigaos.net/index.php/UTF8_ ... icode_Text
It's only used on MorphOS at the moment, although I've added support in newer NetSurf builds as it is slightly better than manually switching between local charset and UTF-8 CHRS (although, actually it supports both options). Scanning through for UTF8 chunks prior to extracting data from either CHRS or UTF8 chunks is not at all friendly through iffparse.library, so I can't see it catching on.

Abandoning FTXT for a different FORM (let's call it UTXT for the sake of argument) that specifies CHRS blocks as UTF-8 might be a better solution, although I'm not sure it will solve the programming issue. The IFF specification is quite happy with "this chunk supercedes that chunk" but iffparse.library doesn't appear to have a mechanism to directly support it, so that is probably the best fix.

It would be easier if the chunk that supersedes another chunk was to always be placed before the chunk that is superseded then you could just ignore it if you encountered the newer chunk type before it.

As this seems not to be the case for UTF8/CHRS chunks maybe instead of parsing the FORM twice you could just start parsing the CHRS chunks as you encounter them but when/if you encounter your first UTF8 chunk you throw away any CHRS data you have and start parsing only the UTF8 chunks.