Do attachments ever get screwed up?
mm
attachments to email?
I have been sending a friend of mine .htm files, and it turns out he
can't read parts of them. One font is totally screwed up, and
displays as a mixture of wierd symbols.
So recently he sent some of them back, as attachments to email. And
though I can still read the original files fine, I can't read the
files he sends back to me any better than he can.
I'm using Eudora 7 and he's using a Macintosh computer.
We're both using Firefox to view the files. I've used FF2 and FF3 and
he uses some Macintosh version, but of course the reader doesn't seem
to be the problem.
I plan to hand him a copy of the file on a floppy, but I'd like a good
way to do this electronically.
John H Meyers
> Are there specific kinds of files
> that can't be successfully sent as attachments to email?
Under "Options" | "Attachments"
the MIME encoding method is an established universal standard,
and should result in any recipient receiving the same file that you sent.
However, HTML files are not interpreted identically by all web browsers,
which accounts for most of the "I didn't see the same as you sent" issues.
You can make sure that an HTML file is actually sent as an attachment,
rather than "inline" (in the message body), by making sure that the
"text as attachment" message composition button (just to the right of "QP")
is depressed, just before sending. This is the default when the option
"put text attachments in body of message" is NOT checked,
but if you use any "stationery," then the setting stored in the stationery
becomes the default, instead of that option.
You could also try "zipping" the file (an "unzip" program should be
available on Mac OS as well), which will always send the file
binary encoded, which should arrive identically, byte for byte.
> I have been sending a friend of mine .htm files, and it turns out
> he can't read parts of them. One font is totally screwed up,
> and displays as a mixture of wierd symbols.
The font (and character set) which one sees
when viewing a web page may vary according to many factors.
If one is saving a web page from a web site
and then mailing the saved file, it may be better
to simply mail a URL of the web site,
so that the other person may instead try directly viewing the site.
If you are composing the HTML yourself, the fonts you have
may not be the same as fonts available to Mac users,
and default character encodings may also differ
between your web browsers.
> So recently he sent some of them back, as attachments to email.
> Though I can still read the original files fine, I can't read
> the files he sends back to me any better than he can.
Can you compare the file he sends back with the file you sent?
What's changed?
--
mm
<jhme...@nomail.invalid> wrote:
>On Mon, 15 Jun 2009 12:00:57 -0500, mm wrote:
>
>> Are there specific kinds of files
>> that can't be successfully sent as attachments to email?
>
>Under "Options" | "Attachments"
>the MIME encoding method is an established universal standard,
>and should result in any recipient receiving the same file that you sent.
Yes, I'm using MIME encodeing. Thanks for your reply.
>
>However, HTML files are not interpreted identically by all web browsers,
>which accounts for most of the "I didn't see the same as you sent" issues.
>
>You can make sure that an HTML file is actually sent as an attachment,
>rather than "inline" (in the message body), by making sure that the
>"text as attachment" message composition button (just to the right of "QP")
>is depressed, just before sending. This is the default when the option
>"put text attachments in body of message" is NOT checked,
Yes, the option is not checked, and I looked at some prior emails and
the button was pushed in. I never touch any of those buttons. (I
know what they do, but I'm happy with the defaults.)
>but if you use any "stationery," then the setting stored in the stationery
>becomes the default, instead of that option.
I do use stationary but not to reply to email that comes in on my
primary addresss. Even in the other cases, I never touched the inline
setting.
>You could also try "zipping" the file (an "unzip" program should be
>available on Mac OS as well), which will always send the file
>binary encoded, which should arrive identically, byte for byte.
I have to send him one file at least once a week, so this would be a
pain, but I'll do it if that's what it takes.
>> I have been sending a friend of mine .htm files, and it turns out
>> he can't read parts of them. One font is totally screwed up,
>> and displays as a mixture of wierd symbols.
>
>The font (and character set) which one sees
>when viewing a web page may vary according to many factors.
>
>If one is saving a web page from a web site
>and then mailing the saved file, it may be better
>to simply mail a URL of the web site,
>so that the other person may instead try directly viewing the site.
I should have sent you more details in the first place. It's a file
he gets from a mailing list, but although it's available, he hasn't
installed the software in his Mac to read it. So he sends it to me, I
convert it and send it back. He does a lot of favors for me too so I
shouldn't complain.
>
>If you are composing the HTML yourself, the fonts you have
>may not be the same as fonts available to Mac users,
>and default character encodings may also differ
>between your web browsers.
That could be. I thought he told me it worked at first, but does that
mean it could be becuase the mailing list changed to a font he doesn't
have? They would probably tell him what font they use and even send
him a copy, if that is within copyright. Would that fix it? I've never
understood copyrights and fonts. There seem to be loads of free
fonts. Are there any that aren't?
If it's a font issue and he installed that program he has, the very
program the mailing list recommends I think, do you think it likely to
have the fonts he needs?
>> So recently he sent some of them back, as attachments to email.
>> Though I can still read the original files fine, I can't read
>> the files he sends back to me any better than he can.
>
>Can you compare the file he sends back with the file you sent?
>
>What's changed?
I used to have two programs, one for text and one binary, for
compares. I guess html is a mixture, but problably requires the
binary comparer. I think I still have them in the win98 partition,
and I suspect at least one of them (from Norton Utilities) works
without being installed. So I should try. If necessary I could
install the whole Norton Utilities package, but it is 9 years old and
I thought I should look for something newer. Well, I found
ncompare.exe and it said it was for win95/98 and wouldn't run on my
current operating system. I've only had winXP for 3 weeks.
I could get into win98 and try it there.
I found FC.exe and when clicked it started and then closed a DOS
window. I probably should try that in win98 also. I've been having
trouble starting win98, which is why I finally installed XP, but it
worked ok a week ago.
Thanks a lot, John, and thanks, Tim.
John H Meyers
> It's a file he gets from a mailing list, but although it's available,
> he hasn't installed the software in his Mac to read it.
> So he sends it to me, I convert it and send it back.
Sending him instructions for installing some software (what?)
might convert a perpetual recurring task into a one-time task.
It's apparently counterproductive to solve this problem,
since leaving it unsolved might be a motivation for him
to install that software and be done with your services :)
> If it's a font issue and he installed that program he has, the very
> program the mailing list recommends I think, do you think it likely
> to have the fonts he needs?
I have no idea what sort of file, or what program, this refers to.
> I used to have two programs, one for text and one binary,
> for comparing files. I guess html is a mixture,
> but problably requires the binary comparer.
HTML (HyperText Markup Language) is plain text,
with embedded "markup tags," for example:
<font face="Comic Sans MS">This text has a designated (Microsoft) font</font>
That's why the issue of the "Text as attachment" button comes up,
because when the attachment is scanned, Eudora will generally see
that it is plain text, hence will think further about whether
to attach it separately or include it within the message body,
since it has that option, controlled by that button.
The ability of Eudora to include such an "attachment" in the message body
is one way to compose HTML separately, yet send it as a message body with Eudora,
rather than being restricted to only the limited elementary HTML
that the internal message composer can produce; it also enables
very large, separately composed plain text to be included,
without having to copy and paste from one application to another.
http://en.wikipedia.org/wiki/Hypertext
http://en.wikipedia.org/wiki/Comic_Sans
> I found FC.exe and when clicked it started and then closed a DOS window.
FC is a command (non-graphical), and runs only in a DOS window,
which you can open in advance: "Start" | "Run" then type: cmd.exe
You can then type and run commands in the DOS window, e.g.:
cd "any path"
fc /? (for syntax help)
fc /w file1 file2 > changes.txt
notepad changes.txt
However, Microsoft also supplies, with Windows 2000 and up,
a much better graphical file (and directory) comparison program:
http://en.wikipedia.org/wiki/WinDiff
http://support.microsoft.com/kb/159214
Microsoft KB 159214 says:
"In Microsoft Windows 2000 and later, Windiff.exe is included
on the original CD-ROM in the Support\Tools folder.
To install the support tools, run Setup.exe from the Support\Tools folder.
Windiff.exe is also in the Support.cab file.
Support.cab is included with every service pack."
Windows XP natively and graphically opens ".cab" archives,
just like ".zip" files, in Windows Explorer,
and can extract any of the included files
(just drag them to the desktop, for example).
WinDiff requires only these files: windiff.exe, gutils.dll, windiff.hlp
(put all three in the same folder, such as in the main Windows folder;
start windiff.exe -- no further installation is required)
--
John H Meyers
Windows XP Service Pack 2 Support Tools [includes Windiff]
http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38
http://www.google.com/search?q=windiff+site:microsoft.com
--
mm
<jhme...@nomail.invalid> wrote:
>On Mon, 15 Jun 2009 23:17:08 -0500, Tim wrote:
>
>> It's a file he gets from a mailing list, but although it's available,
>> he hasn't installed the software in his Mac to read it.
>> So he sends it to me, I convert it and send it back.
>
>Sending him instructions for installing some software (what?)
>might convert a perpetual recurring task into a one-time task.
>
>It's apparently counterproductive to solve this problem,
>since leaving it unsolved might be a motivation for him
>to install that software and be done with your services :)
Good point, but this guy does loads of favors for me, even without my
asking for them, and I'm actually pleased to have a chance to do a
recurring favor for him. Although I certainly didn't seem like that
when I was complaining about having to zip each file for him. I guess
it's becaue that is extra work that I didn't think would be necessary,
but I'm getting used to the idea. So I zipped one as you suggested
and sent it but he hasn't replied yet. **
>> If it's a font issue and he installed that program he has, the very
>> program the mailing list recommends I think, do you think it likely
>> to have the fonts he needs?
>
>I have no idea what sort of file, or what program, this refers to.
I forget the name. I can find it if it would help, but I'm hoping the
zip file will fix it. It wasn't so much work after all. I'm sort of
embarrased that I even brought that up.
>> I used to have two programs, one for text and one binary,
>> for comparing files. I guess html is a mixture,
>> but problably requires the binary comparer.
>
>HTML (HyperText Markup Language) is plain text,
>with embedded "markup tags," for example:
>
><font face="Comic Sans MS">This text has a designated (Microsoft) font</font>
Great.
>That's why the issue of the "Text as attachment" button comes up,
>because when the attachment is scanned, Eudora will generally see
>that it is plain text, hence will think further about whether
>to attach it separately or include it within the message body,
>since it has that option, controlled by that button.
I it must go out as a separate attachment or he would have had reason
to complain from the very beginning. If it were inline text in his
email, he'd have a real hard, or impossible time, getting it into his
web browser, right, and he's never said a word about that.
I may have also sent myself a copy once.
>The ability of Eudora to include such an "attachment" in the message body
>is one way to compose HTML separately, yet send it as a message body with Eudora,
>rather than being restricted to only the limited elementary HTML
>that the internal message composer can produce; it also enables
>very large, separately composed plain text to be included,
>without having to copy and paste from one application to another.
>
>http://en.wikipedia.org/wiki/Hypertext
>http://en.wikipedia.org/wiki/Comic_Sans
>
>> I found FC.exe and when clicked it started and then closed a DOS window.
>
>FC is a command (non-graphical), and runs only in a DOS window,
>which you can open in advance: "Start" | "Run" then type: cmd.exe
>
>You can then type and run commands in the DOS window, e.g.:
>
>cd "any path"
>fc /? (for syntax help)
>fc /w file1 file2 > changes.txt
>notepad changes.txt
Thanks. That's a big help. I'll take one of those he sent me back
and put it with a modified name in the same directory I sent it from,
and do just what you say above.
>However, Microsoft also supplies, with Windows 2000 and up,
>a much better graphical file (and directory) comparison program:
Or I won't. I'll use what you have here.
>http://en.wikipedia.org/wiki/WinDiff
>http://support.microsoft.com/kb/159214
>
>Microsoft KB 159214 says:
>"In Microsoft Windows 2000 and later, Windiff.exe is included
>on the original CD-ROM in the Support\Tools folder.
>To install the support tools, run Setup.exe from the Support\Tools folder.
>Windiff.exe is also in the Support.cab file.
>Support.cab is included with every service pack."
>
>Windows XP natively and graphically opens ".cab" archives,
>just like ".zip" files, in Windows Explorer,
>and can extract any of the included files
>(just drag them to the desktop, for example).
>
>WinDiff requires only these files: windiff.exe, gutils.dll, windiff.hlp
>(put all three in the same folder, such as in the main Windows folder;
>start windiff.exe -- no further installation is required)
Well, I think I want to do this even if zipping the file solves
everything, because I'm curious. But probably not tonight.
Thanks a lot for all the info, and for the post that follows this one.
**
(I also used to take him to the airport once a year, 60 miles away,
and pick him up, but he would also give me money for gas, and more
than the gas cost. I took 20 or 30 less than he offerred but maybe I
still took too much. Anyhow, instead of going to Dulles, he know
trakes the train from Baltiomre to Philly to catch the plane and so I
only have to drive about 7 miles each way, and he doens't give me
anything for gas, which is fine. But he also offers to take me to
the airport and back. I don't think I've needed that, but still.
And he lends me his extension ladder and delivers it and picks it up,
even when I insist it will fit on top of my convertible (with the top
down and a bracket coming off the bumper. And lends tools, etc. etc.
John H Meyers
> I think [the HTML file] must go out as a separate attachment
> or he would have had reason to complain from the very beginning.
> If it were inline text in his email, he'd have a real hard,
> or impossible time, getting it into his web browser, right,
> and he's never said a word about that.
Most email programs, just like Eudora, display included HTML directly,
so this conclusion is not inevitable.
> I may have also sent myself a copy once.
Did you save what you received?
You could also re-open any saved sent message,
and see whether the "Text as attachment" button
is depressed or not (I believe that these states
may be saved in the TOC, and should remain saved
unless the TOC is rebuilt).
--
mm
<jhme...@nomail.invalid> wrote:
>On Tue, 16 Jun 2009 19:58:58 -0500:
>
>> I think [the HTML file] must go out as a separate attachment
>> or he would have had reason to complain from the very beginning.
>> If it were inline text in his email, he'd have a real hard,
>> or impossible time, getting it into his web browser, right,
>> and he's never said a word about that.
Let me give the punch line first so you won't spend time answering
what else I have to say here.
It turns out that one file he sent back to me is 1209 bytes shorter
than the file I sent to him!!!
My mixed.htm was 88,815 When I got his back it was 87,606 bytes.
So I asked him what length it was when he got it. But haven't gotten
an answer.
I guess I should have checked this first since it's simple to check,
but I didn't. That's certainly within the rules of emailing,
although come to think of it, there was a second file in that email,
and before I sent it, I got a warning that the email was long, but it
didn't say it was too long to work right. Is 150K too long to work
right? I thought that was short in the scheme of things.
The other one he also sent back and it was 1361 bytes shorter than
when I sent it, 98,558 instead of 99,921. So instead of taking 2500
bytes off the second one, emailing in one direction or the other took
about 1200 out of each. So total length doesn't seem to be the issue.
I don't know if we will redo prior files, because most of the text was
legible. Since there is a new one every week, maybe I'll send him
lengths with the files. And then there is the zip file, which was
about 30% the size of the original. He still hasn't gotten back to me
about whether that was complete or not.
>Most email programs, just like Eudora, display included HTML directly,
>so this conclusion is not inevitable.
I also know he's been reading these files in his browser, not the
email program. :)
>
>> I may have also sent myself a copy once.
>
>Did you save what you received?
Yeah I've been doing this with him for 6 or 9 months and my inbox and
in2 and in3 are pretty long and it would be easier to just do it
again, especially since he sends me a file every week.
>You could also re-open any saved sent message,
>and see whether the "Text as attachment" button
>is depressed or not (I believe that these states
I did that after your first suggestion. It was depressed (but I tried
to cheer it up.)
John H Meyers
> It turns out that one file he sent back to me is 1209 bytes shorter
> than the file I sent to him!!!
How many lines (rather than bytes) was it?
If every text line that you send, terminated by CRLF under Windows,
is transformed into a one-character Mac line ending,
the Mac file will be shorter, by a byte count
matching the number of lines in the file.
You can readily convert text file line endings under Windows,
using this free (and very good) multi-tabbed text editor:
http://www.editpadpro.com/editpadlite.html
A "Pro" version is also available --
all basic features like "line endings" keep working forever;
some highly advanced features are limited to 30 days free trial:
http://www.editpadpro.com/cgi-bin/affref.pl?aff=jhmeyers
(my "affiliate" link)
--
mm
<jhme...@nomail.invalid> wrote:
>On Wed, 17 Jun 2009 12:38:42 -0500, mm:
>
>> It turns out that one file he sent back to me is 1209 bytes shorter
>> than the file I sent to him!!!
>
>How many lines (rather than bytes) was it?
About 500 lines, each of them.
>
>If every text line that you send, terminated by CRLF under Windows,
>is transformed into a one-character Mac line ending,
>the Mac file will be shorter, by a byte count
>matching the number of lines in the file.
I emailed two of them to myself and when I get them back they're the
same length, in bytes, and display just as well.
My friend couldn't unzip the zipped version, so I don't know if that
will work. I don't even know if it's the same length as when I sent
it because my friend doesn't know how to find out how long any of his
files are. He's going to try to find out.
Maybe he couldn't unzip it because the only place he sees it is listed
as the attachment in the email I sent him. Although I think he can
open links and .pps files, but maybe they are single clicked and
double clicking isn't something that works when one is clicking in the
middle of an email.
>You can readily convert text file line endings under Windows,
>using this free (and very good) multi-tabbed text editor:
>http://www.editpadpro.com/editpadlite.html
I have that. But otoh, my files were only 500 lines long and the
version that came back from Mac is 1200 or 1300 bytes shorter than the
original.
Thanks again for all your help.
John H Meyers
> I emailed two of them to myself and when I get them back
> they're the same length, in bytes, and display just as well.
Sending is okay, then. We don't know what happens on the remote Mac.
> My friend couldn't unzip the zipped version
Why? Can friend unzip other zipped files, from other sources?
If latter is yes, then perhaps friend's received attachment
is corrupted -- since all zipped files
are accompanied by internal checksums,
thoughtful unzipping software should compare each checksum,
and should detect such errors.
> I don't even know if it's the same length as when I sent it
> because my friend doesn't know how to find out
> how long any of his files are.
This does slow down the investigation a bit.
You could try zipping something which is exactly known,
such as the text body of an email,
sent again as a zipped attachment,
which could provide a simple basic test
of the procedures involved.
You could also try attaching two versions of each HTML file --
the original HTML file and a zipped version,
which could be compared with the original after unzipping.
--
mm
<jhme...@nomail.invalid> wrote:
>On Fri, 19 Jun 2009 15:06:14 -0500, mm wrote:
>
>> I emailed two of them to myself and when I get them back
>> they're the same length, in bytes, and display just as well.
>
>Sending is okay, then. We don't know what happens on the remote Mac.
>
>> My friend couldn't unzip the zipped version
>
>Why? Can friend unzip other zipped files, from other sources?
He's probably never tried to unzip anything before.
I'm waiting for a friend of his who uses a Mac to explain this to him.
I sent the friend a copy of the same files and he wrote back and at
least one of them didn't come out right either, but he didn't tell me
what length he got.
Good suggestions below. I'll let you know what happens, but they've
gone out of town for the weekend.