RS> I just strip all but the minimal sequences from ANSI file descriptions.
 RS> I could do something similar for ANSI in message bodies too, but I
 RS> suppose someone might be wanting to post animated ANSIs and want them to
 RS> display as intended.

That is a concern for sure.  My take on that at the time was that there have probably been maybe 10 animated ANSIs worth viewing in the history of ANSI art and that modern buffering on TCP/IP and terminals could also make ANSImation inconsistant.  I felt the benefits far outweighed the ANSImation issue.

I do have an "undocumented" command that will do a raw message dump to the screen without any pre-processing which would allow ANSImation in those rare cases, but so far no one has ever brought this up.

 RS> Do you translate the ANSI clearing and cursor movement sequence to a
 RS> different set of ANSI sequences or are you actually using the ANSI
 RS> region definition sequences to define this "message viewport" and
 RS> letting the terminal handle that?

I am adjusting it.  So a 1;1H would translate to the top of the message view and not actually the first row and first column of the user's terminal, and then any cursor movements are offset like that as well.

It doesn't use any terminal-based boundaries/scroll regions but the end result is about the same as if it did.

 RS> I'm curious how absolute cursor positioning works when the coordinates
 RS> are outside of this "message viewport". Sounds like a lot of work and
 RS> opportunity for wonkiness. :-)

It was a lot of work.  At the time I was driven by some cooler ideas like the art collaboration through message bases. None of that was ever used though, so at the end of the day it is probably most noticed when someone posts an ANSI with a clear screen lol.

I don't think the effort to build something like that is worth it if its just for that clear screen "use-case" (if you can call it that).

... Evil triumphs when good people do nothing. - Einstein

--- Mystic BBS v1.12 A48 2022/03/26 (Windows/64)