<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.3" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Reader Extensions: A Manifesto</title>
	<link>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/</link>
	<description>PDF and Acrobat discussion for users, CIOs and developers</description>
	<pubDate>Fri, 21 Nov 2008 13:02:43 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.3</generator>

	<item>
		<title>by: Duff Johnson&#8217;s PDF Perspective &#187; Blog Archive &#187; Acrobat 8 and the Reader Extensions Manifesto</title>
		<link>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-89</link>
		<pubDate>Thu, 09 Nov 2006 14:34:54 +0000</pubDate>
		<guid>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-89</guid>
					<description>[...] In July, 2006, I introduced the Reader Extensions Manifesto; essentially, a set of checkpoints for assessing the implementation of Reader Extensions in Adobe&amp;#8217;s PDF management software.  The idea was to offer encouragement and guidance to Adobe Systems as they pondered their strategy for moving Reader Extensions to Acrobat Professional. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] In July, 2006, I introduced the Reader Extensions Manifesto; essentially, a set of checkpoints for assessing the implementation of Reader Extensions in Adobe&#8217;s PDF management software.  The idea was to offer encouragement and guidance to Adobe Systems as they pondered their strategy for moving Reader Extensions to Acrobat Professional. [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: thepdfexpert</title>
		<link>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-12</link>
		<pubDate>Sat, 05 Aug 2006 16:18:34 +0000</pubDate>
		<guid>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-12</guid>
					<description>Article 8

This is a big step in the right direction, however, it lacks a fundamental principle. No matter what Adobe thinks and no matter how many resources they expend studying and analysing the saveability of user data, Adobe does not, cannot, and should not have any sort of ownership or control over the data that users input into a PDF form. 

I cannot think of a single exception to this rule except for forms that Adobe uses for its own business purposes. Everything else is off limits to Adobe, plain and simple. 

It's not a matter of law, it's not a matter of profitability, of business rights, or anything else Adobe has conjured up as justification for their RE model. It all boils down to this one thing. User data, how it's produced, how it's used, how it's saved, and who it belongs to is at the sole discretion of the user (and in some cases the forms creator), no exceptions!
  
Whether Adobe charges a government, or a company for the so called right to allow users to Save PDF form data is not the point. Licensing schemes and price tags are not the point. Every version of RE has broken the most fundamental and sacred principle, that the data entered into a form belongs to the person who created it. To limit in any way what a user can do with his/her data can only be described as &quot;data hijacking&quot;.

The ability to Save PDF form data has erroneously been interpreted as some sort of &quot;enhancement&quot; that is worth paying for. This is faulty reasoning. The bottom line is, if Joe Blow spends a minute, an hour, or a day keying data into a form, that work and effort is of value to Joe, it is also Joe's property. Therefore Joe has the innate right to do what he wants with his work, and that includes saving it. Joe's work should not require an &quot;enhancement&quot; at someone else's discretion. No one has the right to deny Joe the benefits of his labor, anymore than denying Adobe the right to make a profit from selling software that it worked hard to create.
 
To generously give away free versions of the Adobe Reader without a form data save feature is a violation of Joe's rights to his work. To enable PDF forms with RE (solely at someone else's discretion) and then only allowing these additional rights to Save Joe's form data ONCE, is also a violation of Joe's rights. 

I routinely hear the argument that users of Adobe Reader can always &quot;save&quot; their data by printing a paper copy. This is a total copout! Not everyone has a printer. Current surveys tell us that there are now more mobile laptop computers in use than stationary desktop units, yet there are very few portable printers or laptops with built-in printers. This paper copy argument is insufficient.


Article 9
 
Yes acroform support! The infamous missing ADBC support in RE is a disgrace. If Adobe doesn't want to support ADBC in RE then they need to resume sales of Acrobat Approval, or a similar product. There is a great need for PDF forms that can communicate with desktop and LAN based databases. I understand Adobe's business goals in regards to LiveCycle and the desire to get enterprises to migrate to it. However, this type of heavy handed tactic is a sure fire way of alienating developers and those who hold the purse strings.</description>
		<content:encoded><![CDATA[<p>Article 8</p>
<p>This is a big step in the right direction, however, it lacks a fundamental principle. No matter what Adobe thinks and no matter how many resources they expend studying and analysing the saveability of user data, Adobe does not, cannot, and should not have any sort of ownership or control over the data that users input into a PDF form. </p>
<p>I cannot think of a single exception to this rule except for forms that Adobe uses for its own business purposes. Everything else is off limits to Adobe, plain and simple. </p>
<p>It&#8217;s not a matter of law, it&#8217;s not a matter of profitability, of business rights, or anything else Adobe has conjured up as justification for their RE model. It all boils down to this one thing. User data, how it&#8217;s produced, how it&#8217;s used, how it&#8217;s saved, and who it belongs to is at the sole discretion of the user (and in some cases the forms creator), no exceptions!</p>
<p>Whether Adobe charges a government, or a company for the so called right to allow users to Save PDF form data is not the point. Licensing schemes and price tags are not the point. Every version of RE has broken the most fundamental and sacred principle, that the data entered into a form belongs to the person who created it. To limit in any way what a user can do with his/her data can only be described as &#8220;data hijacking&#8221;.</p>
<p>The ability to Save PDF form data has erroneously been interpreted as some sort of &#8220;enhancement&#8221; that is worth paying for. This is faulty reasoning. The bottom line is, if Joe Blow spends a minute, an hour, or a day keying data into a form, that work and effort is of value to Joe, it is also Joe&#8217;s property. Therefore Joe has the innate right to do what he wants with his work, and that includes saving it. Joe&#8217;s work should not require an &#8220;enhancement&#8221; at someone else&#8217;s discretion. No one has the right to deny Joe the benefits of his labor, anymore than denying Adobe the right to make a profit from selling software that it worked hard to create.</p>
<p>To generously give away free versions of the Adobe Reader without a form data save feature is a violation of Joe&#8217;s rights to his work. To enable PDF forms with RE (solely at someone else&#8217;s discretion) and then only allowing these additional rights to Save Joe&#8217;s form data ONCE, is also a violation of Joe&#8217;s rights. </p>
<p>I routinely hear the argument that users of Adobe Reader can always &#8220;save&#8221; their data by printing a paper copy. This is a total copout! Not everyone has a printer. Current surveys tell us that there are now more mobile laptop computers in use than stationary desktop units, yet there are very few portable printers or laptops with built-in printers. This paper copy argument is insufficient.</p>
<p>Article 9</p>
<p>Yes acroform support! The infamous missing ADBC support in RE is a disgrace. If Adobe doesn&#8217;t want to support ADBC in RE then they need to resume sales of Acrobat Approval, or a similar product. There is a great need for PDF forms that can communicate with desktop and LAN based databases. I understand Adobe&#8217;s business goals in regards to LiveCycle and the desire to get enterprises to migrate to it. However, this type of heavy handed tactic is a sure fire way of alienating developers and those who hold the purse strings.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Carl Young&#8217;s AcroViews &#187; Blog Archive &#187; Adobe Reader Submit</title>
		<link>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-11</link>
		<pubDate>Tue, 01 Aug 2006 17:19:08 +0000</pubDate>
		<guid>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-11</guid>
					<description>[...] There were a flood of responses, all along the lines of &amp;#8220;No,&amp;#8221; and &amp;#8220;only with Adobe Reader Extensions Server.&amp;#8221; (For more on ARES, see Duff Johnson&amp;#8217;s Reader Extensions Manifesto.) [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] There were a flood of responses, all along the lines of &#8220;No,&#8221; and &#8220;only with Adobe Reader Extensions Server.&#8221; (For more on ARES, see Duff Johnson&#8217;s Reader Extensions Manifesto.) [&#8230;]
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: maxwyss</title>
		<link>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-10</link>
		<pubDate>Wed, 26 Jul 2006 23:19:19 +0000</pubDate>
		<guid>http://www.acrobatusers.com/blogs/duffjohnson/2006/07/25/reader-extensions-a-manifesto/#comment-10</guid>
					<description>Some very good points here. However, I would like to add a few comments, in no particular order.

The first is more a question of terminology: We are talking of &quot;Reader Extensions&quot;, but in most of the post, it would be better called &quot;Extended Rights&quot;. &quot;Reader Extensions&quot; sounds to me more like an application or a component of an application, whereas &quot;Extended Rights&quot; describe in a clearer way, what happens to a document when it gets processed by the Reader Extensions ... here we have the application already mentioned.

To statement 1: To a very little extent, this is already the case with Acrobat 7 (Commenting by e-mail Right). And in a very early development stage, the Reader Extensions were actually a plug-in for Acrobat. Therefore, there are no technical obstacles.

To statement 2: This is a very good point, and it should even be possible to add additional rights to a document with either application.

Statement 3 should actually not be necessary, because there should be no differentiating between a &quot;desktop&quot; (Acrobat-driven) and &quot;server&quot; (Livecycle product-driven) extended document.

Statement 4 implies actually the same.

Statement 5 kind of implies an interesting concept, which would make a lot of sense, even if it might be a bit difficult to communicate: It would essentially mean the possibility to buy the right to grant _specific_ rights. At the moment, it is just all or nothing.

Statement 7 shows another concept (pay per use). However, this might work in countries with no or little privacy legislation, but in countries where privacy legislation is strong, we may run into serious privacy problems.

Statement 8 gets my wholehearted support. The users know what, how, and why they are doing something in a speciific way. Period. 

And Statement 9 gets my wholehearted support as well. In fact, it would be even better to completely merge XFA technology into Acroforms, and then dump it. The original XDP specification implied this, but then they got watered down (or one can also say &quot;corrupted&quot;).</description>
		<content:encoded><![CDATA[<p>Some very good points here. However, I would like to add a few comments, in no particular order.</p>
<p>The first is more a question of terminology: We are talking of &#8220;Reader Extensions&#8221;, but in most of the post, it would be better called &#8220;Extended Rights&#8221;. &#8220;Reader Extensions&#8221; sounds to me more like an application or a component of an application, whereas &#8220;Extended Rights&#8221; describe in a clearer way, what happens to a document when it gets processed by the Reader Extensions &#8230; here we have the application already mentioned.</p>
<p>To statement 1: To a very little extent, this is already the case with Acrobat 7 (Commenting by e-mail Right). And in a very early development stage, the Reader Extensions were actually a plug-in for Acrobat. Therefore, there are no technical obstacles.</p>
<p>To statement 2: This is a very good point, and it should even be possible to add additional rights to a document with either application.</p>
<p>Statement 3 should actually not be necessary, because there should be no differentiating between a &#8220;desktop&#8221; (Acrobat-driven) and &#8220;server&#8221; (Livecycle product-driven) extended document.</p>
<p>Statement 4 implies actually the same.</p>
<p>Statement 5 kind of implies an interesting concept, which would make a lot of sense, even if it might be a bit difficult to communicate: It would essentially mean the possibility to buy the right to grant _specific_ rights. At the moment, it is just all or nothing.</p>
<p>Statement 7 shows another concept (pay per use). However, this might work in countries with no or little privacy legislation, but in countries where privacy legislation is strong, we may run into serious privacy problems.</p>
<p>Statement 8 gets my wholehearted support. The users know what, how, and why they are doing something in a speciific way. Period. </p>
<p>And Statement 9 gets my wholehearted support as well. In fact, it would be even better to completely merge XFA technology into Acroforms, and then dump it. The original XDP specification implied this, but then they got watered down (or one can also say &#8220;corrupted&#8221;).
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
