Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"I think you will all appreciate this person's commenting style"

jwz.livejournal.com

Post reply on HN
Print view View original

61–70 of 91 posts

Re: "I think you will all appreciate this person's commenting style"

#61

Post by to3m »

greggman wrote: post #36

I'm pretty sure the PSD format chucks are based off IFF spec from 1985 http://www.martinreddy.net/gfx/2d/IFF.txt Things were padded to 4 byte boundries because the 68000 processor would crash if you read an unaligned 32bit value. So the length of the actual data was what you find in the size field of each chuck but each chunk is padded. That way you didn't have to work around the 68000 quirks and read a byte at a tim…

I wrote one a few years ago as well. It read layers, summary image, and some layer metadata that I needed (blend mode, layer name, visibility flag, etc.). There's documentation for the format on the adobe site, I think (wherever it came from at the time - autumn 2007 - no fax was required), so it was actually fairly straightforward. An artist made me a bunch of PSD files with the stuff in that they wanted to use, and I sat there comparing the results of my code to what Photoshop did.

The only oddity I can recall is that Photoshop does something odd with the alpha channel - I think it was the alpha channel? - by sometimes storing it with the summary image rather than the layer to which it's related. (Don't ask me for more details than that - I don't remember.) I thought at the time that this looked like somebody's attempt to make newer data work tolerably with older revisions. That part WAS annoying, because the documentation didn't mention that, and it took about a week before somebody managed to create a photoshop file that was arranged this way.

The file format overall bore many of the hallmarks of one that had grown rather than being planned, but it looks like they'd started to clamp down on things at some point because the newer data chunks looked a lot better-designed than the old ones. These things happen. It could be worse. BMP is worse. TGA is worse. They aren't even chunk-based.

Re: "I think you will all appreciate this person's commenting style"

#62

Post by SideburnsOfDoom »

lucian1900 wrote: post #59
SideburnsOfDoom wrote: post #50

Earlier quoted context omitted.

> AFAIK, the Word .doc also started (and unfortunately continued) as basically a not-so-designed memory dump This may be true but not the whole story. It's the reason why the MS office team bit the bullet and replaced .doc with .docx about 5 years ago http://en.wikipedia.org/wiki/Office_Open_XML Docx is basically XML in a zip file. It's a beast and has lots of compromises for backward compatibility, but as a design s…

It's still worse than ODT (which itself isn't exactly pretty), for no good reason. That's sad.

ODT is also XML-based, to Docx's problems compared to ODT can't be blamed on XML.

Re: "I think you will all appreciate this person's commenting style"

#63

Post by brudgers »

TeMPOraL wrote: post #55
SideburnsOfDoom wrote: post #52

Earlier quoted context omitted.

Hm, interesting. Could you explain why the decision to use (zipped) XML in the current MS Office document formats was a mistake? Those document formats are huge hideous beasts, but that's due to backward compatibility with large feature sets, and I don't think that moving off XML would help. PS: I fixed the typo in "lesson"

The deicision was a big step forward; however, moving off XML to an equivalent but less verbose (in number of meaningless bytes) format wouldn't hurt. All else being equal, it would be less electricity wasted on reading and sending things over the wire, and also more human-readable format. See also: SEXP vs. XML. This argument applies the more, the bigger markup-to-data ratio is.

The wide availability across numerous platforms of robust libraries and tools for manipulating XML along with its standardization and the ubiquity of its implementation might have played a role in Microsoft's decisions.

Re: "I think you will all appreciate this person's commenting style"

#64

Post by sabret00the »

jacobolus wrote: post #15
saurik wrote: post #2

PSD was never intended to be a data interchange format: it is the serialization format of a single program that has more individual unrelated features that actual people rely on than almost any other piece of software and has maintained striking amounts of backwards compatibility and almost unbroken forwards compatibility during its over two decades of existence. This product's "file format" needs to be critiqued in…

Further points: 1) The specs are now much more publicly accessible than they used to be, and frankly the spec does a fairly reasonable job describing a tricky format relatively compactly. It requires a fair bit of knowledge of Photoshop to read and understand, but it’s mostly fairly explicit. Much better than many other proprietary document formats. 2) For someone with relatively extensive knowledge of photoshop, the…

So just out of curiosity, why doesn't Adobe embark on those two projects? We're entering a new era of desktop software, surely that should be a catalyst for redesigning both from scratch?

Re: "I think you will all appreciate this person's commenting style"

#65

Post by saurik »

yason wrote: post #37
saurik wrote: post #2

PSD was never intended to be a data interchange format: it is the serialization format of a single program that has more individual unrelated features that actual people rely on than almost any other piece of software and has maintained striking amounts of backwards compatibility and almost unbroken forwards compatibility during its over two decades of existence. This product's "file format" needs to be critiqued in…

If a wise programmer decided he needs a serialization format, would he deliberately include in that format all the crap so vividly pointed to by the article? No. He will think of the "serialization format" as an interchange format between two different instances of his program. One process first writes the data file and another process later will read it. He also knows that sooner or later the "serialization format"…

You are making a general argument why serialization formats should not exist. Fine, but in reality, and for any number of reasons, they do: they are easier at first, they are actually often somewhat easier over time, the pain cost that occurs is often easily amortized over time, they are fast to load (no transformations), they are fast to edit (you can often treat them as some insane memory page container and do internal allocation for updates, leaving old content begin until it is recycled), and their concept makes them capable of handling random seemingly-unrelated garbage that these mega-programs end up being popular for.

They aren't even always considered the non-ideal: I have seen many an argument from people who use Smalltalk that the ideal transfer format is to literally serialize part of the running program state and call it a "document", including whatever code might be required to operate the more epic parts of the document. (If you think about it, this is actually fairly similar to the various file formats that involve OLE, as you end up having the identifier of some code the user hopefully has installed attached with a block of data that that code hopefully can reinstate ate itself using.)

So, given that it is a tradeoff, and given that it was often a neccessary one for file formats where you want or need to be able to edit files that both contain numerous nearly-unrelated features (OLE would be the most beautiful example of this in the Word container format) where the entire contents may be larger than the RAM available to the entire computer, it simply seems silly to complain about this: man up, import the data, make your own format for saving your files, and stop complaining that someone in 1990 made something that over 22 years has become slightly difficult to understand without that historical context.

Re: "I think you will all appreciate this person's commenting style"

#66

Post by saurik »

Camillo wrote: post #43
saurik wrote: post #2

PSD was never intended to be a data interchange format: it is the serialization format of a single program that has more individual unrelated features that actual people rely on than almost any other piece of software and has maintained striking amounts of backwards compatibility and almost unbroken forwards compatibility during its over two decades of existence. This product's "file format" needs to be critiqued in…

> I am thereby having a difficult time fathoming why anyone would think that a PSD file is thereby going to be some well-organized file format that they should easily be able to parse from their own application is just naively wishful thinking I like how you embodied your point in the unsyntax of that very sentence. ;)

Two hours latereader read what I wrote, and thought "man, this comment's upvotes to correct grammar ratio is remarkably high" (this is after one hour later, when I noticed another serious typo in the first few words that I still had time to edit). If it makes any difference to you: I write most of these comments I make on my iPhone, so I often can't even see the whole horizontal line at once. ;P

Re: "I think you will all appreciate this person's commenting style"

#67

Post by worldsayshi »

sabret00the wrote: post #64
jacobolus wrote: post #15

Earlier quoted context omitted.

Further points: 1) The specs are now much more publicly accessible than they used to be, and frankly the spec does a fairly reasonable job describing a tricky format relatively compactly. It requires a fair bit of knowledge of Photoshop to read and understand, but it’s mostly fairly explicit. Much better than many other proprietary document formats. 2) For someone with relatively extensive knowledge of photoshop, the…

So just out of curiosity, why doesn't Adobe embark on those two projects? We're entering a new era of desktop software, surely that should be a catalyst for redesigning both from scratch?

And cut all backwards compatibility in doing so? Risky move indeed. Not so sure the benefits would make up for it.

Re: "I think you will all appreciate this person's commenting style"

#68

Post by JoeAltmaier »

saurik wrote: post #2

PSD was never intended to be a data interchange format: it is the serialization format of a single program that has more individual unrelated features that actual people rely on than almost any other piece of software and has maintained striking amounts of backwards compatibility and almost unbroken forwards compatibility during its over two decades of existence. This product's "file format" needs to be critiqued in…

Um, they could have had a process for how to extend the format. Even GIF has a definition for how to add new pieces. PSD apparently had a process:play it by the seat of your pants?

Now, Word docs are xml format. Pretty extensible.

Re: "I think you will all appreciate this person's commenting style"

#69

Post by nollidge »

sabret00the wrote: post #64
jacobolus wrote: post #15

Earlier quoted context omitted.

Further points: 1) The specs are now much more publicly accessible than they used to be, and frankly the spec does a fairly reasonable job describing a tricky format relatively compactly. It requires a fair bit of knowledge of Photoshop to read and understand, but it’s mostly fairly explicit. Much better than many other proprietary document formats. 2) For someone with relatively extensive knowledge of photoshop, the…

So just out of curiosity, why doesn't Adobe embark on those two projects? We're entering a new era of desktop software, surely that should be a catalyst for redesigning both from scratch?

Because they could knit sweaters instead and it would have about the same impact on their bottom line.

Re: "I think you will all appreciate this person's commenting style"

#70

Post by JoeAltmaier »

TeMPOraL wrote: post #55
SideburnsOfDoom wrote: post #52

Earlier quoted context omitted.

Hm, interesting. Could you explain why the decision to use (zipped) XML in the current MS Office document formats was a mistake? Those document formats are huge hideous beasts, but that's due to backward compatibility with large feature sets, and I don't think that moving off XML would help. PS: I fixed the typo in "lesson"

The deicision was a big step forward; however, moving off XML to an equivalent but less verbose (in number of meaningless bytes) format wouldn't hurt. All else being equal, it would be less electricity wasted on reading and sending things over the wire, and also more human-readable format. See also: SEXP vs. XML. This argument applies the more, the bigger markup-to-data ratio is.

its zipped; nothing is wasted.
Post reply on HN