NDIF and self mounting image files cannot be directly transmitted on the Internet because they have resource forks. BinHex and MacBinary encoding convert the image to a data fork–only file that can be safely uploaded to Web and FTP servers, even using software that’s improperly configured or not Mac-savvy. MacBinary produces smaller files than BinHex, but some older software can only decode BinHex.
If you choose an encoding other than None, DropDMG will encode images so that you end up with a .hqx file, a .bz2 file, a .gz file, or a .bin file. If you select BZip2 or GZip, the image will be compressed a second time, in addition to the zlib/ADC/NDIF compression that is intrinsic to the image format. This will make the resulting file a bit smaller.
Some Web servers have trouble handling plain .dmg files, because they don’t know what kind of file they are. When people download the .dmg file, it can open in the Web browser instead of mounting automatically. Or, with a bzip2-compressed image, Safari will change the file extension from .dmg to .dmg.bz2, which causes the OS to think the file is damaged. In order to prevent these problems, make sure that your Web server uses the correct MIME type for .dmg files. If you administer an Apache-based server, you can ensure this by adding this line:
AddType application/x-apple-diskimage .dmg
to your .htaccess file. If you cannot do this on your server, you can use encoding to eliminate the problem, at the expense of an extra decoding step after downloading.
BZip2 is slower than GZip but compresses better. MacBinary offers no compression at all, so it is fast. BZip2 and GZip are disabled for NDIF images because they do not work with files that have resource forks.
If you use encoding in combination with segments, DropDMG will encode each segment of the image. Some segments may compress better than others, so it is normal for the segments to be of unequal size after encoding.