RS> Okay, I'm doing the same/similar in my msglist module. I just render the
RS> ANSI to a virtual CGA-style screen buffer and then send the relevant
RS> portions of that buffer to the user as they scroll the message 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.

I do the same thing for importing FILE_ID.ANS format which is something I made
up at some point over the years...

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

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.

.... No one knows what's next, but everybody does it.

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