Welcome to the Office Mac Help Site About | Blog | Links | Glossary | Feedback | Downloads | Help

FAQs: Compression

  1. How do I set compression for my attachments?
  2. Windows users can't open my attachments
  3. Can I create rule that for particular addresses and automatically change encoding?

More on AppleDouble and AppleSingle by Rich Siegel here.

Factoid: You can compress stuff for free using Entourage 2004. Entourage includes a license to use the StuffIt engine.


1) How do I set compression for my attachments?

When sending to both Mac and Windows users at the same time, use AppleDouble encoding.

When sending to Mac only, use AppleDouble. This sends both resource and data forks for Mac users, but may be confusing to some Windows users because there will be two files for each attachment, one readable, one garbage (the resource fork).

When sending to Windows only, use Windows (MIME/Base64) encoding. This excludes the (Mac-only) resource fork and sends only the data fork, which is all they need.

If you do want to compress (optional), use Stuffit and include somewhere in your message the link to download Expander free. If you know for sure they can handle Stuffit archives, then by all means use Stuffit compression.

Note: if you send a file that has a Macintosh Resource Fork (e.g. A graphic file with a preview & custom icon) the windows recipient MAY receive two files - the first (with the original file name) being the data fork, and useable to him or her, the second (the original name with an exclamation mark preprended) is the stuff from the resource fork and is useless to those on windows.


2) Windows users say they can't open my attachments. What do I need to do?

In the Mail & News preferences, under the Compose tab there are boxes to set your preferred encoding and compression method. When sending to Windows users, make sure the compression is set to "NONE" and that encoding is set to either "Any Computer" or "Windows". These settings can also be changed on a message-by-message basis by clicking on the long button (which displays the current encoding/compression scheme) underneath the attachments pane in a message window. Be sure to check "Append Windows extensions to file names."

Note: if you send a file that has a Macintosh Resource Fork (e.g. A graphic file with a preview & custom icon) the windows recipient MAY receive two files - the first (with the original file name) being the data fork, and useable to him or her, the second (the original name with an exclamation mark preprended) is the stuff from the resource fork and is useless to those on windows.


3) I have one client that always has trouble with attached PDF files. I have solved the problem by changing the encoding of the email to Windows (MIME/Base64). Is it possible to create a rule that will work when I type this clients email address in and automatically changes the encoding?

No, but why don't you change your preference to always send in Base64 encoding by default? The only scenario this encoding won't work for is sending a Mac file with a required resource fork, such as an application.


AppleDouble and AppleSingle

By Rich Siegel, Bare Bones Software

AppleSingle and AppleDouble are both -binary- packaging conventions, and do not specify or imply the transfer encoding.

It's very important to understand the difference between "packaging" and "transfer encoding". On the Mac, packaging is pretty important because Mac files consist of three components: data fork, resource fork, and file info. So to transfer a Mac file in its entirety, you need to package it up such that it can be recreated by the receiving client.

Since many transfer links or lesser email clients can only handle US ASCII characters, it's usually desirable to encode a binary file so that it can be transmitted across a 7-bit link and recreated on the other side. The "transfer encoding" specifies the fashion in which this is done, and is essential to transmitting non-ASCII files via email, regardless of the sending or receiving platform.

UUcode and BASE64 are both transfer encodings; they take any binary data as input, and convert it to a pure ASCII form which can be transmitted over any text-only link. UUcode is slightly more specialized, because it was originally designed for transmitting files over text-only UUCP links, and thus contains a "begin" line, which specifies the file name and the Unix permissions for that file. (That's what the "644" is.) BASE64 is newer, and can be used to encode any arbitrary stream of data.

AppleSingle and AppleDouble are both packaging conventions: they take any Mac file, and "flatten" it into a representation which can be stored on any non-Mac file system, and then subsequently recreated into the original Mac file. After packaging a file with AppleSingle or AppleDouble, a transfer encoding -must- be applied if the file is to be transmitted across a 7-bit link (such as email).

If you're writing to a correspondent who is on a Mac, using any modern Mac email client, it really doesn't matter what you use for either packaging or transfer encoding - all of the currently available clients can handle various combinations of packaging and transfer encoding.

If you're sending a Mac file to a correspondent who's not using a Mac, but who can handle the data of a Mac file (be it text or any other format), use AppleDouble. If the email client he's using is suitably advanced, then it will be able to present the data portion of the file. Again, it doesn't matter what transfer-encoding you use, assuming that the recipient's email client is reasonably modern.

If you're sending a Mac file to a correspondent who's not using a Mac, but the Mac file must be used in its entirety (data, resources, info) and no part is disposable, then use AppleSingle. Your correspondent will more than likely need a Mac to use the file anyway, but AppleSingle is a packaging that can be transported across multiple (non-Mac) platforms and from which the original Mac file can be re-created in its entirety. If any part of an AppleDouble package is lost, you'll be unable to recreate the original file.

As with AppleDouble, the transfer-encoding is irrelevant so long as the receiving client can decode it. Most modern clients can handle BASE64 and decode it.

Notice that I haven't mentioned BinHex. That's because it only adds to the confusion, because it combines -both- binary packaging -and- transfer encoding. In general, you should only use BinHex to encode files that you're sending to someone who is using a Mac - but as I pointed out, if they're using a Mac, it really doesn't matter what you use.

Finally, observe in all of this that I haven't mentioned compression. There's a reason for this - it's a rat's nest of possibilities. For another thing, the choice of compression is independent of binary packaging and transfer encoding. If you're sending a compressed file, use whatever format your correspondent can handle - just as if you were sending an ordinary document.