<?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 for Webbish Books</title>
	<atom:link href="http://webbishbooks.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://webbishbooks.com</link>
	<description>for learning webbish and making better eBooks</description>
	<lastBuildDate>Fri, 17 Feb 2012 19:13:33 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Comment on Share Kindle highlights on Facebook by Araby</title>
		<link>http://webbishbooks.com/2010/09/share-kindle-highlights-on-facebook/#comment-188</link>
		<dc:creator>Araby</dc:creator>
		<pubDate>Fri, 17 Feb 2012 19:13:33 +0000</pubDate>
		<guid isPermaLink="false">http://webbishbooks.com/?p=210#comment-188</guid>
		<description>Took me a while to find something official about a limit. In the documentation there&#039;s a note in parentheses about a 100-character limit on Notes, but I don&#039;t see anything similar about Highlights. I&#039;ve also seen &quot;100 words&quot; mentioned as the comment box limit on blogs, but haven&#039;t been able to verify that on Amazon. The only reference I&#039;ve found so far is on the Amazon UK site: &lt;a href=&quot;http://www.amazon.co.uk/gp/help/customer/display.html?nodeId=200504380#share&quot; rel=&quot;nofollow&quot;&gt;http://www.amazon.co.uk/gp/help/customer/display.html?nodeId=200504380#share&lt;/a&gt;.

Facebook status/group/wall posts used to have a limit of 420 characters (which would be about 100 words), but that was increased to 63206 characters in November 2011.</description>
		<content:encoded><![CDATA[<p>Took me a while to find something official about a limit. In the documentation there&#8217;s a note in parentheses about a 100-character limit on Notes, but I don&#8217;t see anything similar about Highlights. I&#8217;ve also seen &#8220;100 words&#8221; mentioned as the comment box limit on blogs, but haven&#8217;t been able to verify that on Amazon. The only reference I&#8217;ve found so far is on the Amazon UK site: <a  href="http://www.amazon.co.uk/gp/help/customer/display.html?nodeId=200504380#share" rel="nofollow">http://www.amazon.co.uk/gp/help/customer/display.html?nodeId=200504380#share</a>.</p>
<p>Facebook status/group/wall posts used to have a limit of 420 characters (which would be about 100 words), but that was increased to 63206 characters in November 2011.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Share Kindle highlights on Facebook by julia bloom</title>
		<link>http://webbishbooks.com/2010/09/share-kindle-highlights-on-facebook/#comment-187</link>
		<dc:creator>julia bloom</dc:creator>
		<pubDate>Fri, 17 Feb 2012 03:47:05 +0000</pubDate>
		<guid isPermaLink="false">http://webbishbooks.com/?p=210#comment-187</guid>
		<description>Has anyone noticed anything about a limit to how long your shared highlight can be? I highlighted a paragraph in my e-book, shared it to Facebook, but on Facebook the passage was cut off after roughly 100 words.</description>
		<content:encoded><![CDATA[<p>Has anyone noticed anything about a limit to how long your shared highlight can be? I highlighted a paragraph in my e-book, shared it to Facebook, but on Facebook the passage was cut off after roughly 100 words.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Kindle book cover size by Araby</title>
		<link>http://webbishbooks.com/2010/12/kindle-book-cover-size/#comment-173</link>
		<dc:creator>Araby</dc:creator>
		<pubDate>Thu, 26 Jan 2012 12:42:15 +0000</pubDate>
		<guid isPermaLink="false">http://webbishbooks.com/?p=273#comment-173</guid>
		<description>I just excavated your comment from my spam filter... Must have been the link. Yes, as I mentioned in my comment above, a pixel is a pixel, and the dimensions of the inside cover should always be 600x800 pixels. As I noted, resolution data is actually DISCARDED when saved for web or devices in Photoshop. Amazon mixes things up a bit by saying, in one place, to make the inside cover image 600x800, and in another, to use 300dpi/ppi, where they talk about images in general. I&#039;ve been meaning to make this clearer in the post as well, but got pulled off into other projects, so mea culpa.

Some time ago, I ran across an article that explained print and screen resolution in great detail, but it was too technical for general readers. Your explanation, with a diagram that demonstrates how an image appears larger or smaller depending on the resolution of the &lt;em&gt;monitor/output device&lt;/em&gt; may help folks get their head around this fact.

I still prefer to work with a bigger TIFF image for the product catalog because it&#039;s processed by Amazon to make various size thumbnails and for pan and zoom images, when used. I had also observed that when I provided Amazon with the same 600x800 image for the product catalog, they didn&#039;t bother processing for zoom and pan. Now it doesn&#039;t matter much because most books end up with an Inside the Book preview that displays the inside cover image anyway.

</description>
		<content:encoded><![CDATA[<p>I just excavated your comment from my spam filter&#8230; Must have been the link. Yes, as I mentioned in my comment above, a pixel is a pixel, and the dimensions of the inside cover should always be 600&#215;800 pixels. As I noted, resolution data is actually DISCARDED when saved for web or devices in Photoshop. Amazon mixes things up a bit by saying, in one place, to make the inside cover image 600&#215;800, and in another, to use 300dpi/ppi, where they talk about images in general. I&#8217;ve been meaning to make this clearer in the post as well, but got pulled off into other projects, so mea culpa.</p>
<p>Some time ago, I ran across an article that explained print and screen resolution in great detail, but it was too technical for general readers. Your explanation, with a diagram that demonstrates how an image appears larger or smaller depending on the resolution of the <em>monitor/output device</em> may help folks get their head around this fact.</p>
<p>I still prefer to work with a bigger TIFF image for the product catalog because it&#8217;s processed by Amazon to make various size thumbnails and for pan and zoom images, when used. I had also observed that when I provided Amazon with the same 600&#215;800 image for the product catalog, they didn&#8217;t bother processing for zoom and pan. Now it doesn&#8217;t matter much because most books end up with an Inside the Book preview that displays the inside cover image anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Kindle book cover size by Paul Cormier</title>
		<link>http://webbishbooks.com/2010/12/kindle-book-cover-size/#comment-154</link>
		<dc:creator>Paul Cormier</dc:creator>
		<pubDate>Wed, 11 Jan 2012 17:58:09 +0000</pubDate>
		<guid isPermaLink="false">http://webbishbooks.com/?p=273#comment-154</guid>
		<description>To help ease some confusion, it should be noted that ppi and dpi are irrelevant when saving your image. Those refer to the pixel or &quot;dot&quot; density of an OUTPUT device. Your bitmap image is simply a grid of pixels that is of a certain absolute number of pixels wide and tall. 

Whatever graphics tool you use, you only need to pay attention to the width and height in pixels of the final JPG image you save. Any dpi setting can effectively be ignored.

I have a blog post titled &lt;a href=&quot;http://www.webmasterymadesimple.com/blog/is-your-website-the-right-width-part-1-pixels-resolutions.html&quot; title=&quot;Is Your Website the Right Width? Part 1 - Pixels &amp; Resolutions&quot; rel=&quot;nofollow&quot;&gt;Is Your Website the Right Width? Part 1 - Pixels &amp; Resolutions&lt;/a&gt; that helps explain this better.</description>
		<content:encoded><![CDATA[<p>To help ease some confusion, it should be noted that ppi and dpi are irrelevant when saving your image. Those refer to the pixel or &#8220;dot&#8221; density of an OUTPUT device. Your bitmap image is simply a grid of pixels that is of a certain absolute number of pixels wide and tall. </p>
<p>Whatever graphics tool you use, you only need to pay attention to the width and height in pixels of the final JPG image you save. Any dpi setting can effectively be ignored.</p>
<p>I have a blog post titled <a  href="http://www.webmasterymadesimple.com/blog/is-your-website-the-right-width-part-1-pixels-resolutions.html" title="Is Your Website the Right Width? Part 1 - Pixels &amp; Resolutions" rel="nofollow">Is Your Website the Right Width? Part 1 &#8211; Pixels &amp; Resolutions</a> that helps explain this better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Kindle Maximum Image Size by Araby</title>
		<link>http://webbishbooks.com/2011/01/kindle-maximum-image-size/#comment-151</link>
		<dc:creator>Araby</dc:creator>
		<pubDate>Fri, 06 Jan 2012 22:10:51 +0000</pubDate>
		<guid isPermaLink="false">http://webbishbooks.com/?p=365#comment-151</guid>
		<description>Yes, pretty much. Any image can be zoomed by selecting in the reader, so there&#039;s some advantage of using a higher resolution when it&#039;s really important (such as with a map that has tiny lettering), if you can keep the file-size down. (I&#039;ve only bothered with this once, for a gray-scale line map saved as GIF, 16 shades of gray, 150ppi. When zoomed, it looked very clear. At viewing-area size, not quite as readable.)

Theoretically, dingbats or drop-caps shouldn&#039;t be a problem if you include the dimensions in the img tag. If you don&#039;t, they might quadruple in size unexpectedly. Joshua Tallent published some information on the points at which images trigger resizing to full-width or full-height. Lately, it seems that the safe dimensions are much less, and I&#039;ve had images that should have been alright, blow up on-screen in Kindle 3, but not in Kindle Previewer.

You can make your own test grids by creating a file 525x640px, white background. Select some rectangular areas and fill some with black horizontal line patterns and others with black vertical line patterns, using the paint-can. Create whatever size images you want to test from this image. Save for web/devices as GIF or PNG. They will have very small file sizes, and don&#039;t need to be perfect. but with straight lines, it&#039;s easy to spot distortion.

HTML tables that fit within the viewing area display okay on newer kindles, but not Kindle 1. If too big to fit, an image is the best solution. To avoid problems with a short table presented as an image, it might be advisable to put it on a white background the width of the viewing area. User can zoom in to full-screen by selecting the image. If a table also approaches half the height, I would make an image that fills the viewing area. A short but wide table could be made into a rotated image that fits the screen vertically but is only as wide as it needs to be. Most people will rotate the screen clockwise to view a landscape image, so when creating the image, rotate it 90deg counter-clockwise.</description>
		<content:encoded><![CDATA[<p>Yes, pretty much. Any image can be zoomed by selecting in the reader, so there&#8217;s some advantage of using a higher resolution when it&#8217;s really important (such as with a map that has tiny lettering), if you can keep the file-size down. (I&#8217;ve only bothered with this once, for a gray-scale line map saved as GIF, 16 shades of gray, 150ppi. When zoomed, it looked very clear. At viewing-area size, not quite as readable.)</p>
<p>Theoretically, dingbats or drop-caps shouldn&#8217;t be a problem if you include the dimensions in the img tag. If you don&#8217;t, they might quadruple in size unexpectedly. Joshua Tallent published some information on the points at which images trigger resizing to full-width or full-height. Lately, it seems that the safe dimensions are much less, and I&#8217;ve had images that should have been alright, blow up on-screen in Kindle 3, but not in Kindle Previewer.</p>
<p>You can make your own test grids by creating a file 525x640px, white background. Select some rectangular areas and fill some with black horizontal line patterns and others with black vertical line patterns, using the paint-can. Create whatever size images you want to test from this image. Save for web/devices as GIF or PNG. They will have very small file sizes, and don&#8217;t need to be perfect. but with straight lines, it&#8217;s easy to spot distortion.</p>
<p>HTML tables that fit within the viewing area display okay on newer kindles, but not Kindle 1. If too big to fit, an image is the best solution. To avoid problems with a short table presented as an image, it might be advisable to put it on a white background the width of the viewing area. User can zoom in to full-screen by selecting the image. If a table also approaches half the height, I would make an image that fills the viewing area. A short but wide table could be made into a rotated image that fits the screen vertically but is only as wide as it needs to be. Most people will rotate the screen clockwise to view a landscape image, so when creating the image, rotate it 90deg counter-clockwise.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

