Subj : (Possibly) Ignorant Question
To : Daniel Torrey
From : Richard Webb
Date : Tue Dec 25 2012 01:56 am
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? :-)
<hmmm> 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.
