Maybe the other person has confused zipping a file (lossless) with jpeg compression (lossy) which can make test look ugly.
–
Matt HMay 13 '11 at 2:54

I know that I once had compatibility problems for zip files, because the file format is used on all platforms...
–
jokoonMay 13 '11 at 12:11

1

I've certainly experienced certain 'pathological' cases where both Winrar and WinXP's built-in facilities broke files (tens of thousands in a single zipfile). This was 4-5 years ago, and the only solution I could find at the time was to use 7-zip. As best I can remember, even 7-Zip couldn't successfully unzip files created by the other routines, suggesting the fault was in the zipping, not the unzipping. Obviously I opted to use 7-zip for both sides in the production system anyway.
–
FumbleFingersMay 13 '11 at 13:51

1

@jokoon: I'm not sure it's valid to speak of a file format...used on all platforms. There are quite a few different internal formats used in zip files, and it's always possible an archive could be created by one packing routine using a format that's imperfectly supported by some other routine that you happen to use at time of unpacking.
–
FumbleFingersMay 13 '11 at 13:55

@Fumble; But still, any decent archiver should catch the hash change and report the operation as a failure - not leave a broken file lying around.
–
PhoshiMay 14 '11 at 10:34

That is what I suspected. Thanks for your answer.
–
alexMay 13 '11 at 2:41

32

In addition, some zip formats support redundancy, meaning storing as a zip can actually be safer than storing the plain file.
–
BlueRajaMay 13 '11 at 4:25

You should not say no this quickly, there are a lot of zipping/unzipping file implementations out there, counting all existing OSes and other stuff which can make zip files, I would not be surprised that some implementations just don't care of some others.
–
jokoonMay 14 '11 at 17:23

@jokoon: then those files would be corrupted, which he excludes explicitly
–
mbxMay 14 '11 at 20:51

2

-1 In theory this is true, but in practice there are issues with Mac fonts being unzipped on a PC as 0 bytes. This is due to a resource fork being created. Try it for yourself and see.
–
Django ReinhardtMay 15 '11 at 13:54

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.

New to me and bizarre. When is a file not a file? When its contents mutate at will. I've heard of worse misfeatures, but not many.
–
mswMay 13 '11 at 10:56

7

@msw - they don't mutate at will; simply - there can be more than one hunk of data associated with a single file record. Almost always there is exactly one (it is very rarely used), but...
–
Marc Gravell♦May 13 '11 at 11:03

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.

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.

+1 - I wish I could give this enough points to push it to the top of the stack. Mac OS have both Type 1 and TrueType font variants where the font data is stored in the resource fork. While the native zip/unzip tools in the OS can handle this situation gracefully, not all tools (particularly command lines tools ported to OS X) will. What's worse, not zipping the fonts and trying to send them via email or FTP will break them!
–
afrazierMay 13 '11 at 14:46

1

But the problem here appear to be with how you compress them, not whether you can. Seems like to need a program that understands resource forks and you have to know how to use it. Am I reading that right?
–
uSlackrMay 13 '11 at 20:51

@uSlackr, right, but the problem persists at the receiving end. If the archive is then moved Windows, you will likely get a stack of useless font files because although Windows (specifically NTFS) does allow for multiple data streams in a file, fonts on Windows don't work that way. The PSD file itself is likely to be portable betwenn Mac and Windows, however.
–
RBerteigMay 14 '11 at 0:45

+1 - as an example, save your Mac fonts on a network drive and then see how big they are from a Windows or Linux PC - 0 bytes! It is the resource fork thingy confusing the 'it just works' idea.
–
ʍǝɥʇɐɯMay 15 '11 at 11:48

Yes, it's a well known fact in my industry that Mac fonts don't zip well. Often a PC user will unzip them 0 bytes.
–
Django ReinhardtMay 15 '11 at 13:53

irrelevant since zip is using lossless compression (or 'storage', compression could be disabled). checksumming is only to beeing able to provide some feedback if something went wrong.
–
akiraMay 13 '11 at 5:07

13

Forgive the pedantry, but ZIP doesn't use a checksum - it uses a 32 bit cyclic redundancy check (aka CRC-32) which detects a much wider range of errors.
–
BevanMay 13 '11 at 9:08

5

The term "checksum" has clearly become somewhat broader in meaning than its original definition if people can [and they do] call the results of cryptographic hash functions "checksums".
–
Random832May 13 '11 at 14:36

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.)

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.

I think there is a misunderstanding to the concept of a lossless compression algorithm and programs that perform this task. Lossless means, the binary stream that is compressed will be decompressed to the identical output binary stream. Meta informations are OS dependent and have to be handled by the OS and/or the application.
–
BoraMay 14 '11 at 21:08

1

Thanks, @Bora, but I have no such misunderstanding. I realise zipping doesn't affect the actual data in the file. I am suggesting an "external" cause that may fool people into thinking the zip damaged their files and directories. I have been caught in the past by restoring zipped up backups, only to find that my applications no longer worked, because they depend on meta-data I didn't bring across. (Not a basic misunderstanding on my part, but merely an oversight.)
–
OddthinkingMay 15 '11 at 2:31

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.