I just asked someone to send me a zipped psd file.
They declined, citing that zipping a file can break the fonts.
I assumed zipping a file is perfectly reversible, hence why it is commonly used. I think the other person is incorrect.
Is there any truth about zipping breaking its files' contents?
No, zipping a file cannot break it. Providing your zip file is not corrupted, it will reproduce the identical file when unzipped.
In this case, difference between fonts installed on the two different systems may cause issues but that is completely unrelated to the zip/unzip process.
In general usage, zip is lossless (assuming a bug-freeimplementation), but there is one scenario that could apply to data-loss: NTFS Alternate Data Streams. This little-used feature allows a single file to have multiple independent sets of contents. Most code will only ever see the unnamed stream, but others can exist.
So; if a program decided to store the data in an NTFS Alternate Data Stream, your zip client won't see that portion (it needs to explicitly ask for it, and RAR is the only one that does this currently).
But to emphasise: this is used very rarely, and not normally with things like PSD. I suspect your friend/associate is simply wrong.
There are circumstances in which a Mac font may not be identical if it is zipped and then unzipped. This may not break it, but contrary to some statements above, the process may not provide an identical file.
The circumstances are discussed here:
http://ask.metafilter.com/59789/How-to-email-my-font
But in short:
If they are much older fonts that contain resource forks and the user has an older version of Mac OS X, typically 10.4 or earlier. Legacy fonts like this work on OS X though they were originally intended for OS 9 and earlier versions of the Macintosh operating system. It is entirely likely (and, in my experience, common) that some folks are still using a font library they built as long as 20 years ago. Typically these are artists and art director types. For example, I have a few fonts with creation dates of 1993 and hundreds with creation dates of 1998, most with resource forks. Certainly I should have converted these to more modern formats or stopped using them, but let's face it: once you buy the Adobe Font Library, you never want to buy it again. In my years working with art directors in advertising, I learned to respect the font folder as if it were an art director's diary, commonplace book, or superego.
Some metadata will be stripped in certain versions of the operating system. Metadata may be things added to the information field of the file. This will not break the file, but again, nor will the roundtrip zip-unzip produce an identical file.
PS: I am assuming here that if one is zipping a PSD file for delivery to another person, that it has not been flattened and that the font has not been converted to outline, which means that one would also deliver the font files with the PSD so that the person on the receiving end could make their own changes to the file. This is a common practice.
ZIP uses checksum to check if the unpacked file is exactly the same as it was before packing.
So if it was changed in some reason (broken archive, for example) - it would not even be unpacked.
Only if they're doing something silly like doing text-mode conversion on it, or if there's a broken zip/unzip somewhere that gets confused by an embedded zip. (Such bugs have occurred in the past — meaning maybe 10 years ago.)
Zip uses a loss-less compression algorithm to ensure that data you get back is identical to the data you put in.
(BTW, Other technologies like jpg, mpeg, mp3, use lossy techniques to compress with the theory that our eyes and ears are not so sensitive )
The only truth I could see in the statement "zipping breaks fonts" is if the PSD file format itself has a "compressed" version or option you can enable in whatever program creates these files and this option somehow handles fonts differently.
Using any zip program should be fine except if it's buggy.
In response to Marc, there are also potential filesystem issues on EXT filesystems if you try and zip a directory structure containing soft and hard links in a zipped format that doesn't understand these (which is why I always make a .tar.gz instead of a .zip there). Also, zipping soft links with relative paths then unzipping them somewhere else won't of course work, but that's not the zip program's fault.
If they have had that issue before (zipping corrupting a PSD) then either their compressor software is faulty, they are not including all the files they need on the PSD, and/or their computers are infected with a virus.
I would ask them if they have had similar corruptions by moving files to usb disks, just to discard that last option.
Just to add one more caveat for completeness: Zipping may cause the file's meta-data, such as permissions or last-accessed-time to be lost.
I do not believe that is generally relevant to PSD files and fonts.
Zip can corrupt filenames. Zip as such does not use unicode. The encoding of filenames is unspecified and on windows current locale is used.
Therefore when transferred to a different system your filenames will be messed up.
There is an extension to Zip format that most recent programs (winzip since version 11 I think) use.
I prefer 7z eversince I had a zip full of japanese names unable to unzip it.
A zip file is supposed to be able to reproduce the contents exactly.
One related note though -- it is more difficult to recover the data if a zip file gets corrupt, than if the data was in the original format. Why? Many file formats have built in redundancy, and are designed so that either minor errors are correctable, or minor errors are not critical.
Imagine a video file. In most formats, if a small portion gets corrupt, you will see a temporary flicker in that small portion of the video but can still watch the video. But if the video file is zipped, the error correction capability is reduced, and depending on the extent of corruption, you simply may not be able to unzip the file / watch the video. (This is contrived example as it is useless to zip most video formats in any case).
This is true for any compression format - compression by definition reduces reduncancy and hence error correction capabilities and its a trade-off.
