1. Forum
  2. fsxNet
  3. fsxNet Test Arena

  • Hrm...

    From Thom Miller@21:2/145 to All on Wed Apr 12 11:34:16 2023
    Hrm. Okay. So the 'msgtmp' that was pulled into T.A.G. on that last message had the first few sentences as one long line with no linebreaks (i.e. the *editor* is not inserting line breaks). In T.A.G. itself, none of the sentences have the strange i character. In the package that's being sent, the first few characters that I didn't manually hit 'enter' on *had* the accented i in front of them in the packet viewer I used to examine it, but the ones with a manual carriage return before them did not. So either T.A.G. is adding them to the message when it inserts them into the jam message files or fastecho is adding them when it pulls the messages out of the jam message files and packs them up.

    I *think* it's fastecho. As part of this 'connect old technology to new' project, I've been working on a utility to export jam message areas to JSON. When I run that utility and export the data from T.A.G., I'm not seeing anything strange in the JSON file it's exporting... Curiouser and curiouser...

    ---
    * Origin: WalledCTTY (21:2/145)
  • From Nightfox@21:1/137 to Thom Miller on Wed Apr 12 12:00:41 2023
    Re: Hrm...
    By: Thom Miller to All on Wed Apr 12 2023 11:34 am

    Hrm. Okay. So the 'msgtmp' that was pulled into T.A.G. on that last message had the first few sentences as one long line with no linebreaks (i.e. the *editor* is not inserting line breaks). In T.A.G. itself, none of the sentences have the strange i character. In the package that's being sent, the first few characters that I didn't manually hit 'enter' on *had* the accented i in front of them in the packet viewer I used to examine it, but the ones with a manual carriage return before them did not. So either

    I *think* it's fastecho. As part of this 'connect old technology to new' project, I've been working on a utility to export jam message areas to JSON. When I run that utility and export the data from T.A.G., I'm not seeing anything strange in the JSON file it's exporting... Curiouser and curiouser...

    I heard that ASCII 141 (0x8D) is considered a soft-CR in FidoNet, and the echomail processor for the BBS software I'm using (Synchronet) has an option to strip those soft-CRs from incoming messages (if they're not UTF8-encoded). I had that turned off, and I've turned that on. So for Synchronet systems, that may be something to enable.

    Nightfox
    --- SBBSecho 3.20-Linux
    * Origin: Digital Distortion: digdist.synchro.net (21:1/137)