TZUTC: -0700   
   MSGID: 7724.mystic@1:103/705 26a75d0b   
   REPLY: 1:129/215 1bef928e   
   PID: Synchronet 3.19c-Linux master/b5cce30f9 Mar 28 2022 GCC 8.3.0   
   TID: SBBSecho 3.15-Linux master/b5cce30f9 Mar 28 2022 GCC 8.3.0   
   COLS: 80   
   BBSID: VERT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.104   
     Re: Re: ANSI Ad   
     By: g00r00 to Rob Swindell on Mon Mar 28 2022 11:17 am   
      
    >  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   
    >  RS> to 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.   
      
   Oh, I've seen some awesome animated ANSIs. I assume you've seen the Star Wars   
   one (wasn't that ANSI?), but yeah, posting them to message bases has always   
   been pretty uncommon. And with today's transfer rates, the result is usually   
   not what was intended (especially those written back in the 2400-9600bps days).   
      
    > 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.   
      
   Okay, I'm doing the same/similar in my msglist module. I just render the ANSI   
   to a virtual CGA-style screen buffer and then send the relevant portions of   
   that buffer to the user as they scroll the message body. So if there's any   
   overwriting or clearing in the ANSI, they only get/see the final result. This   
   discussion inspired that enhancement, so thanks to Joe!   
      
    >  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).   
      
   I see ANSIs BBS ads posted that use a lot of vertical cursor movement too. Not   
   just screen clears.   
      
   Filtering out the old "ANSI bombs" (keyboard remapping via ANSI.SYS) is a good   
   idea too. Remember those?   
   --    
                                               digital man (rob)   
      
   This Is Spinal Tap quote #44:   
   It really, it does disturb me, but i'll rise above it; I'm a professional.   
   Norco, CA WX: 58.9øF, 70.0% humidity, 8 mph ENE wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.15-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 1/123 15/0 90/1 103/705 105/81 106/201 120/340 123/131 124/5016   
   SEEN-BY: 129/305 330 331 153/757 7715 154/10 203/0 218/700 840 221/0   
   SEEN-BY: 221/1 6 242 360 226/30 227/114 229/110 206 307 317 400 424   
   SEEN-BY: 229/426 428 452 550 664 700 230/0 240/5832 266/512 280/464   
   SEEN-BY: 280/5003 282/1038 292/854 8125 301/1 317/3 320/219 322/757   
   SEEN-BY: 335/364 341/66 234 342/200 396/45 423/81 460/58 633/280 712/848   
   SEEN-BY: 2452/250 4500/1   
   PATH: 103/705 280/464 221/1 6 229/664 426