Hello Daniel,

On Mon 2012-Dec-24 08:15, Daniel Torrey (1:132/505) wrote to Richard Webb:

DT> It's Squish/386 version 1.11, running on DOS. Well, actually,
DT> running in a DOXBox window, which is running in a Windows 7 VM,
DT> which is running in Parallels Desktop on a Macbook Pro, which is
DT> running OS X 10.8.2. Why do it the easy way?  :-)

  Wonder if the mac os might be translating things
funny, lots of things strange there.  I run same version,
under dos itself.  Others do under various win flavors as
well, so that might have something to do with the problem of wrong character.

 RW> FIrst thing I note is your squish is using the undersc ore
 RW> character, ascii 95 instead of the regular dash character,
 RW> ascii 45.

DT> Interesting. Squish is putting in whatever it wants to by default;
DT> I'm not defining a tearline anywhere, just an origin line. If Squish
DT> thinks that ASCII 95 is the correct character to use in the tear,
DT> that would explain why it's adding one even if there's a previous
DT> (ASCII 45) tear in the message, added buy GOldED+ - if Squish is
DT> looking for three 95 chars and what's there is 3 45 chars.

Hmmm, our mac guys could probably address that one, don't
know where to go for that one, and doubt many of them are
here.

DT> There's no GoldED+ tear in the messages I'm sending out because I've
DT> configured GoldED+ to not add one - I don't want to end up with two,
DT> which is what was happening when I was testing.

I'm wondering if through all the vm stuff and then the mac
os that ascii 45 might be interpreted as ascii 95.

DT> Thanks for your help, I'll see what I can figure out.

This one's a new one on me.  I know that if squish sees a
msg without an origin line, it will place the one you define at the end of the
message, and of course a tear line at that point.

Regards,
           Richard
---
 * Origin:  (1:116/901)