Some thoughts about the PSD format(blogs.adobe.com)
blogs.adobe.com
Some thoughts about the PSD format
http://blogs.adobe.com/jnack/2009/05/some_thoughts_about_psd.html
6 comments
I'm going out on a limb and guessing you've never written an application of any complexity that required it's own binary file format. I don't mean that as a slag, but your comments leads me to believe that is the case and, therefore, your understanding of the issue is purely speculative.
I also think you missed the point, PSD is not designed to be an interchangeable format nor a public one. It is designed to operate specifically with it's origin application, therefore why should Adobe care if third party developers have a hard time implementing it? That's not their problem. There is no onus on Adobe to create some magic file format that third party developers can easily implement.
What is their problem is a performant file format with backwards and forwards compatibility that must store a lot of application specific stuff. Stuff that only their application needs to deal with.
As someone who has written a PSD importer for Delphi (in Pascal!) using Adobe's docs, it's really not that terribly difficult for most use cases. It's just as clear as working with any other RIFF-esque file format. You can write a simple importer in a couple of days, and a more in-depth one within a week.
ymmv, ianal.
I also think you missed the point, PSD is not designed to be an interchangeable format nor a public one. It is designed to operate specifically with it's origin application, therefore why should Adobe care if third party developers have a hard time implementing it? That's not their problem. There is no onus on Adobe to create some magic file format that third party developers can easily implement.
What is their problem is a performant file format with backwards and forwards compatibility that must store a lot of application specific stuff. Stuff that only their application needs to deal with.
As someone who has written a PSD importer for Delphi (in Pascal!) using Adobe's docs, it's really not that terribly difficult for most use cases. It's just as clear as working with any other RIFF-esque file format. You can write a simple importer in a couple of days, and a more in-depth one within a week.
ymmv, ianal.
Somewhere in the Joel on Software Excel article, Spolsky makes the point that most Office features, most buttons and checkboxes, have to be represented in the file format somehow. That graf hit me like a punch in the gut. Sure, there are tangible benefits to an improved file format. But Nack's point is really, is it worth it for Adobe to undertake that kind of surgery to provide it?
Maybe I'm crazy but the artice, which was obviously meant to rebut the criticism of PSD, really ended up confirming every piece of criticism.
The only real counterpoint was backwards compatibility and to be honest I don't think that's really valid. With a computer savvy group like Photoshop users I suspect you could introduce a format that addresses all the criticism with minimal disruption.
The only real counterpoint was backwards compatibility and to be honest I don't think that's really valid. With a computer savvy group like Photoshop users I suspect you could introduce a format that addresses all the criticism with minimal disruption.
>With a computer savvy group like Photoshop users I suspect you could introduce a format that addresses all the criticism with minimal disruption.
You've clearly never worked with the bottom 80% of the talent pool :) Many professional designers come from a print background which, by its nature, is not very technically demanding.
You've clearly never worked with the bottom 80% of the talent pool :) Many professional designers come from a print background which, by its nature, is not very technically demanding.
It's a rebuttal to "A sane format would pick one.". This is an explanation of why PSD is not insane. The primary point is that the use cases and expected users are not what our ranting developer might have liked.
It also rebuts the idea that Adobe makes people "sign[] in blood" for specs.
On both counts, whether you consider it adequate is up to you. Personally, I've been involved in enough stuff that the format makes some sense to me (reverse compatibility in a binary format means you make crazy choices by any other standard), but I'm somewhat unconvinced by the second one. If all it takes to get the specs is a fax, you might as well at least turn that into an email, or just put them up on the web... but that's just my opinion.
It also rebuts the idea that Adobe makes people "sign[] in blood" for specs.
On both counts, whether you consider it adequate is up to you. Personally, I've been involved in enough stuff that the format makes some sense to me (reverse compatibility in a binary format means you make crazy choices by any other standard), but I'm somewhat unconvinced by the second one. If all it takes to get the specs is a fax, you might as well at least turn that into an email, or just put them up on the web... but that's just my opinion.
>Maybe I'm crazy...
You are not crazy. I drew the same conclusion you did. There was no discernible refutation.
You are not crazy. I drew the same conclusion you did. There was no discernible refutation.
If I were to say "Ruby is a terrible language to write a first-person shooter in!", you would naturally say, "Of course. That's not really its sweet spot." Then I could say
> There was no discernible refutation.
> There was no discernible refutation.
This article suggests that adobe offer the PSD docs to solve the problem of reverse engineering, but to get the docs you have to sign an NDA, which means you can't publicly release the source code. If they had a more sane licensing policy, the comments in that code wouldn't have ever needed to be written in the first place.
The NDA is a red herring. Most developers on software that doesn't have a 20 year legacy would have the same complaints even if the format was documented rigorously for them. The Joel on Software article Nack cites really is an effective rebuttal.
On the other hand, we really are making a big deal out of a random code comment. I don't know why Nack is perpetuating the story.
On the other hand, we really are making a big deal out of a random code comment. I don't know why Nack is perpetuating the story.
[deleted]
[deleted]
So PSD is undeniably an incoherent piece of legacy crap. What's so wrong with that that Adobe/Adobeans feel they have to explain themselves - do they feel ashamed somehow? All that is needed is to just accept that it's far from perfect. It doesn't mean it's wrong or they're stupid or whatever.
Many old formats are crap; heck, you might even expect any old format to be crap in a way or another! You can only write a clear, consistent format specification after the fact when you know everything the format needs to capture.
Even if the basic structure is simple, such as in XML or AVI/RIFF, developers only proceed to write hacky extensions in terms of that very basic structure. The complexity just arises on a higher level, then.
Many old formats are crap; heck, you might even expect any old format to be crap in a way or another! You can only write a clear, consistent format specification after the fact when you know everything the format needs to capture.
Even if the basic structure is simple, such as in XML or AVI/RIFF, developers only proceed to write hacky extensions in terms of that very basic structure. The complexity just arises on a higher level, then.
Almost every file format is flawed in one way or another; time has a way of changing your assumptions and magnifying flaws.
This could not be more wrong. Time and brainpower are limited resources. Building a parser for an ugly format takes more time and consumes more brainpower. It pisses off the developer, who then thinks less clearly. And it requires the developer to repeatedly do research, which breaks his focus. The developer needs to write more code for an ugly format, and optimizing and maintaining such code becomes difficult. If the code is organically evolving (alongside the format), then with each iteration, fewer and fewer people understand the entirety of the code and format, and fewer and fewer people are able to bring good ideas to the table. The developer is angry, confused, mired in a bunch of ugly code, and alone. He will never produce his best work.
None of this is to bash Adobe for producing PSD. Every organization of sufficient age has eldritch code. It is arcane and ancient, and if you look at it the wrong way, it will crumble to dust and blow away in a sudden wind. The problem is arguing that it doesn't matter if mere mortal developers cannot understand it, or that there are no concrete benefits to end users from producing clean internals. The detriments of ugly internals may not be directly visible to users, but users definitely see the ripples on the surface.