I have a question, g00r00 can answer, or anyone for that matter... Is there any reason why in the year 2022 other BBSes cannot support ANSI in the message bases/readers.
On 08 Mar 2022, IB Joe said the following...
I have a question, g00r00 can answer, or anyone for that matter... Is there any reason why in the year 2022 other BBSes cannot support ANSI the message bases/readers.
Modern BBS packages support ANSI in the message bases. Even some
"legacy" BBS packages support ANSI in the message bases (some with more success than others) while other BBS packages won't display ANSI at all (showing nothing but garbly goop).
Since this is a federated network and we can't control who sees what on which system we tend to cater to the lowest common denominator.
Some message networks allow ANSI in certain bases only (BBS ads for example) while others encourage adding an [ANSI] tag in the subject so those that can't display ANSI can skip those messages.
Jay
Modern BBS packages support ANSI in the message bases. Even some
"legacy" BBS packages support ANSI in the message bases (some with more
I have a question, g00r00 can answer, or anyone for that matter... Is
Some legacy software accidentally supports ANSI in messages because it spits out data to the terminal as its saved.
Mystic renders everything server-side and in the case of the message reader it presents it to you in a scrollable reading window.
I have a question, g00r00 can answer, or anyone for that matter... Is
I think the way Mystic handles this is just something no one else has
felt the need to support? I don't really have a reason why.
Synchronet puzzles me So... Rob et. al. actively works on that project and you'd think that's where I wouldn't have an issue. I don't think about things, because Mystic handles this flawlessly...
Re: Re: ANSI Ad
By: IB Joe to Jay Harris on Tue Mar 08 2022 06:06 pm
Synchronet puzzles me So... Rob et. al. actively works on that project you'd think that's where I wouldn't have an issue. I don't think about things, because Mystic handles this flawlessly...
So Mystic ignores or strips your clear-screen sequence (while Synchronet does not)? Please clarify what "handles flawlessly" means in this
context. --
On 25 Mar 2022, Rob Swindell said the following...
Re: Re: ANSI Ad
By: IB Joe to Jay Harris on Tue Mar 08 2022 06:06 pm
Synchronet puzzles me So... Rob et. al. actively works on that project you'd think that's where I wouldn't have an issue. I don't think about things, because Mystic handles this flawlessly...
So Mystic ignores or strips your clear-screen sequence (while Synchronet does not)? Please clarify what "handles flawlessly" means in this
context. --
Sorry... if someone post an ad, or any message with ANSI in it, Mystic reads the message as it is posted and meant to be viewed. When Mystic reads a message with plain text or ANSI it displays both of them, the ANSI in the message has no affect to the reader.
It seems though, with other BBS packages... Yours isn't the only one... The same happens with WINServer and other packages. If there is ANSI in the message it affects how the messages are displayed to the user.
I post ANSI ads, as others do, and I never really thought too much about things because when I'm on my mystic system they display nicely... If I logon to a SynchroNET or my WINServer system the message is not displayed nicely... message header gets pushed up...
You can see this anytime you want... Logon to any Mystic BBS and read BBS ads section... then go do that with your package and you'll see the difference.
Rob, I'm just an end user and had questions as to why other systems weren't handling ANSI with their message readers like Mystic does.
I didn't mean to come across the wrong way... I just had questions... I was half hoping that it was something to do with how messages are stored...
It sounds like Mystic is not actually rendering your ANSI as you entered it, i.e. your clear-screen sequence isn't actually clearing the user's screen.
It sounds like Mystic is not actually rendering your ANSI as you entered it, i.e. your clear-screen sequence isn't actually clearing the user's screen.
Mystic renders ANSI in message content in the context of the message viewport. In other words, Mystic knows that a clear screen in an uploaded ANSI message should clear only the message viewport not the entire user's terminal, and it acts accordingly.
The same holds true for all ANSI commands, cursor movements, clear screen/lines, etc. They are rendered in the context of the message viewport, not the entire user's terminal.
You can mix and match ANSI and text inline with the message editor that has TheDraw-like features, and Mystic will save and render it WYSIWYG in your message bases. This was something I originally did in the early 2000s so that people could co-create ANSI art within actual message bases and then download the completed ANSIs...
But these days its mostly just a factor when people post ANSI BBS ads lol
Mystic applies a similar methodology to ANSI file descriptions too when using things like FILE_ID.ANS.
Anyway, thats why a clear screen in a traditional BBS will clear the entire screen but Mystic it only clears the "message viewport".
Hope that helps clear things up.
I just strip all but the minimal sequences from ANSI file descriptions.
I could do something similar for ANSI in message bodies too, but I
suppose someone might be wanting to post animated ANSIs and want them to display as intended.
Do you translate the ANSI clearing and cursor movement sequence to a different set of ANSI sequences or are you actually using the ANSI
region definition sequences to define this "message viewport" and
letting the terminal handle that?
I'm curious how absolute cursor positioning works when the coordinates
are outside of this "message viewport". Sounds like a lot of work and opportunity for wonkiness. :-)
I just strip all but the minimal sequences from ANSI file descriptions. I could do something similar for ANSI in message bodies too, but I suppose someone might be wanting to post animated ANSIs and want them 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.
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.
Do you translate the ANSI clearing and cursor movement sequence to a different set of ANSI sequences or are you actually using the ANSI region definition sequences to define this "message viewport" and 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.
I'm curious how absolute cursor positioning works when the coordinates are outside of this "message viewport". Sounds like a lot of work and 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).
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!
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!
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.
the final result. This discussion inspired that enhancement, so thanks
to Joe!
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.
Yeah, we've had this "graphic.js" library
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. :-)
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!
| Sysop: | altere |
|---|---|
| Location: | Houston, TX |
| Users: | 66 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 18:22:44 |
| Calls: | 633 |
| Calls today: | 7 |
| Files: | 7,638 |
| Messages: | 291,889 |