<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The PSD File Format</title>
	<atom:link href="http://mjtsai.com/blog/2009/05/05/the-psd-file-format/feed/" rel="self" type="application/rss+xml" />
	<link>http://mjtsai.com/blog/2009/05/05/the-psd-file-format/</link>
	<description></description>
	<lastBuildDate>Thu, 18 Mar 2010 20:01:44 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Aristotle Pagaltzis</title>
		<link>http://mjtsai.com/blog/2009/05/05/the-psd-file-format/comment-page-1/#comment-499650</link>
		<dc:creator>Aristotle Pagaltzis</dc:creator>
		<pubDate>Wed, 06 May 2009 01:14:18 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/?p=1910#comment-499650</guid>
		<description>Thanks for saying exactly what I thought.

The problems Ågren pointed out basically go back to one point: either PSD was never designed with extensibility in mind (and whenever extended, a clean mechanism for further extensions was not a consideration), or all of the existing extension mechanisms were wilfully ignored over and over.

Consider JFIF, GIF and PNG. All of these formats had a structural extensibility mechanism from the start – as a result, contemporary versions of files in those formats can contain information that was not foreseen at the time of their specification, and yet the complexity of decoding those formats has stayed nearly constant since the beginning.

Of course, JFIF, GIF and PNG always had interoperation as a goal; PSD was only ever designed as an opaque house-internal binary blob for Adobe’s purposes and no one else’s. So the directions taken by those formats are really no surprise.</description>
		<content:encoded><![CDATA[<p>Thanks for saying exactly what I thought.</p>
<p>The problems Ågren pointed out basically go back to one point: either PSD was never designed with extensibility in mind (and whenever extended, a clean mechanism for further extensions was not a consideration), or all of the existing extension mechanisms were wilfully ignored over and over.</p>
<p>Consider JFIF, GIF and PNG. All of these formats had a structural extensibility mechanism from the start – as a result, contemporary versions of files in those formats can contain information that was not foreseen at the time of their specification, and yet the complexity of decoding those formats has stayed nearly constant since the beginning.</p>
<p>Of course, JFIF, GIF and PNG always had interoperation as a goal; PSD was only ever designed as an opaque house-internal binary blob for Adobe’s purposes and no one else’s. So the directions taken by those formats are really no surprise.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: KinOfCain</title>
		<link>http://mjtsai.com/blog/2009/05/05/the-psd-file-format/comment-page-1/#comment-499640</link>
		<dc:creator>KinOfCain</dc:creator>
		<pubDate>Tue, 05 May 2009 23:16:46 +0000</pubDate>
		<guid isPermaLink="false">http://mjtsai.com/blog/?p=1910#comment-499640</guid>
		<description>This is a conversation that comes up a lot in software development where a piece of software has &quot;evolved&quot; over time and someone feels that it&#039;s necessary to defend the end result with a history of how it got there. It&#039;s perfectly justifiable to explain WHY the end result sucks, but the end result still sucks.</description>
		<content:encoded><![CDATA[<p>This is a conversation that comes up a lot in software development where a piece of software has "evolved" over time and someone feels that it's necessary to defend the end result with a history of how it got there. It's perfectly justifiable to explain WHY the end result sucks, but the end result still sucks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
