TZUTC: -0700   
   MSGID: 7731.mystic@1:103/705 26a7b551   
   REPLY: 1:129/215 595f0a56   
   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 03:25 pm   
      
    >  RS> Okay, I'm doing the same/similar in my msglist module. I just render   
    >  RS> the ANSI to a virtual CGA-style screen buffer and then send the   
    >  RS> relevant portions of that buffer to the user as they scroll the message   
    >  RS> body. So   
    >  RS> if there's any overwriting or clearing in the ANSI, they only get/see   
    >  RS> the final result. This discussion inspired that enhancement, so thanks   
    >  RS> to Joe!   
    >   
    > Cool stuff.  Thats basically what Mystic does.  It pre-processes everything   
    > and works along the lines of something like curses.   
      
   Yeah, we've had this "graphic.js" library for a long time for doing that kind   
   of stuff (ANSI viewers/editors, etc.) and I just needed to make proper use of   
   it in my message lister/viewer.   
      
    > I do the same thing for importing FILE_ID.ANS format which is something I   
    > made up at some point over the years...   
      
   Ah, I didn't know that. I priorize importing FILE_ID.ANS over .DIZ. I do wish   
   that they'd stick to a reasonable maximum column width however. The   
   Blocktronics artpacks have some pretty wide ones. Good for testing things with   
   though.   
      
    > Mystic will render the ANSI to a local buffer to get the final result, and   
    > then convert that buffer into pipe codes internally before storing it (so   
    > that it shows as non-color to those who don't have it or full color for   
    > those that do using existing display system)...   
      
   Yup, I do something very similar but with Ctrl-A codes. I really try not to   
   store/use raw ANSI anywhere in Synchronet unless the sysop insists on it. :-)   
      
    > It can then easily be stripped of pipe codes for things like .TIC files,   
    > file list compilers or whatever else may be required to not have color/codes   
    > in them.  And people who create the FILE_ID.ANS don't have to worry about   
    > stripping codes or doing really anything extra to make it work, it just   
    > shows up the same as it does when they save it in their ANSI editor.   
      
   Hopefully. ANSI editors can do all kinds of crazy stuff with cursor   
   positioning, etc., but yeah, for basic color/attribute control, the results   
   should be the same. I hadn't yet thought about the stripping of color codes   
   when hatching files. That's a good idea.   
   --    
                                               digital man (rob)   
      
   Sling Blade quote #18:   
   Karl Childers: Some folks call it Hell, I call it Hades.   
   Norco, CA WX: 58.5øF, 66.0% humidity, 0 mph ENE wind, 0.12 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