Archive for the 'Kindle' category

Send to Kindle

Mar 20 2013 Published by under Kindle

Just a quick note that I added the “Send to Kindle” plugin to the site here. At the bottom of each post you should see a Send to Kindle button that will prompt you to log in to your Amazon account and send that post to  any registered Kindle. I know it’s something I do a lot with posts I’m reading on other sites via the Chrome extension. So it’s nice that Amazon has created this.

Just pointed out to me that the button might be better on the top of the post. I originally put it at the bottom, because that’s where the other “share” type buttons go. But it’s a good point because you see those buttons when you are done reading, but you might want to see this one before you read. So I put it in both places! Looks silly on a short post like this, but fine on a larger one.

Comments are off for this post

My Kindle Authoring Setup Part 2 – now with Markdown!

May 13 2012 Published by under Kindle

As I was writing the previous post on my Kindle Authoring Setup, it occurred to me that markdown might be a solution to having to mark everything up with HTML tags. So I wrote a comment in there exactly as it hit my brain. After publishing that post, I went ahead and checked it out and it has worked beyond what I imagined.

First, I located the command line tool, pandoc (again, cross-platform, yay!) and installed that. Then I did some tests and was amazed how much it did. Read up on markdown syntax and was even further amazed. I’d say this writing/publishing flow is now as close to perfect as it can get.

First of all, I changed my concat target in the build.xml to use pandoc instead of ant’s concat.

    <target name="concat">
        <exec executable="pandoc">
            <arg value="-o"/>
            <arg value="${html_file}"/>
            <arg value="book/"/>
            <arg value="book/"/>
            <arg value="book/"/>
            <arg value="book/"/>

Here we specify the output file with -o plus the output file name, then the list of input files. It will concatenate them and convert them from markdown to HTML, using the file extensions to determine the format.

Some brilliant things about markdown that make it perfect for this format:

H1’s can be either:

# This is a header


This is a header

Since I’m using H1’s for chapter names, I like the underline format.

H3’s, which I’m using for sections, become:

### This is a section title

All other paragraphs are just plain text. p tags are added automatically.

It automatically does the smart quote replacements.

Surrounding underscores like _this_ become em tags (italicized in the book).

Surrounding asterisks like *this* become strong tags (bolded).

There is also markdown for images, but I’m fine with keeping the HTML image tags in there. Any inline HTML in a markdown doc is automatically preserved, with some caveats as mentioned in the above referenced syntax doc. I’ll switch over to markdown syntax for images though, just to keep everything in one format.

If that were all there was, I’d be thrilled. But it does even more.

Any blocks of text that are indented with at least 4 spaces or 1 tab are surrounded with pre and code tags! Furthermore, any angle brackets in that section are turned into their HTML entity equivalents. So basically I can copy and paste my code as is. All I need to do it tab it over 4 spaces.

Finally, inline code style, like this are accomplished with back quotes `like this`.

Couldn’t be happier with this setup right now. I’m basically writing straight up plain text with straight up plain copy and pasted code and it’s all formatting to a perfect ebook with one click of a button.

6 responses so far

My Kindle Authoring Setup

May 13 2012 Published by under Kindle, Uncategorized

As mentioned previously, I have started working on self-publishing my Playing With Chaos book on the Amazon Kindle self publishing service. I quickly got the outline, first chapter, part of the second, some code and images done. Then last weekend I decided I better check into the whole publishing process in a bit more detail. I went through all the material on Amazon’s site, as well as several other tutorials. I even downloaded a free ebook on Kindle publishing and paid for another 99 cent book on the subject. I learned a lot, but none of it made me very happy to begin with. Here’s why:

Pretty much every reference starts out telling you to write your book in Microsoft Word. Now don’t get me wrong – I think Word is a great tool as long as you are writing in word and then printing your documents out, or sending them to someone else who will view them in Word. It’s a super powerful application with every tool you could possibly imagine for writing almost anything. But where Word gets really ugly is its export functionality. I’ve done some professional work trying to convert exported Word docs into other formats. It was one long, horrible headache.

Workflow #1

The simplest possible workflow is:

1. Write your book in Word.
2. Upload to Kindle and let Amazon turn it into a Kindle ebook.

I suggest you try this. When you’re done looking at the results and wiping up your own vomit, we can move on.

Workflow #2

The next workflow, which is what most resources will recommend is:

1. Write your book in Word.
2. Save it as a filtered web page.
2a. Optionally clean up the HTML.
3. Zip and upload the HTML and other files to Amazon.
3a. Alternately, run it through another program to create a .mobi file and upload that to Amazon.

Doing steps 1, 2 and 3, without the optional/alternate steps will essentially give you the result of the first workflow. But I also suggest you do steps 1 and 2 and look at the results. This will give you an idea of why it’s such a mess. For my 1.5 chapter book in progress, the resulting HTML file was composed of 50% CSS, 50% HTML. All kinds of custom styles going on there. 99% of which will be ignored.

For step 2a, several pages I found offered advice on the various things to clean up and delete or change from the HTML/CSS. Nobody offered an automated solution. This gives you a workflow like this:

A. Write some of your book.
B. Export it to HTML.
C. Go through a lengthy, manual, painful process of cleaning up the HTML by hand.
D. Convert it to .mobi or upload it to Amazon.
E. Preview it.
F. Write some more of your book.
G. Do B-E again.

No thanks.

Now let’s move on to step 3a. There are three main tools used for converting HTML to .mobi.

– kindlegen

This is Amazon’s command line tool, so it must be good, right? Wrong. It’s known to be buggy and its output is just incorrect. It was my first choice, despite the warnings I’d read on various sites. There are Windows, Mac and Linux versions. And it’s command line! How could I not try it. But I soon found myself agreeing with the warnings and abandoned it.

– Mobipocket Creator

This is a Windows-only tool that will take documents of various types and convert them into ebooks. I tried this, but didn’t like it too much. It has a very consumery feel to it. Seems like it tries to over-automate the process for you, making all the decisions for you. Probably with a bit more investment of time, I could learn to control it more, but I was also not thrilled about the Windows-only part. And the fact that it’s a graphic interface tool, which I’ll discuss more in depth shortly.

– Calibre

The third choice is mentioned by a few, but seems to scare away most people. It’s triple platform – a big plus. In fact, I think it began as a linux tool. It also exposes just about every possible option you could ever want to tweak on your import/convert/output workflow. A bit overwhelming at first, but I liked that. While the main program is a graphical tool, I soon found out that it all just sits over a suite of command line tools that expose all those possible options. I was onto something big here!

Workflow #3

I quickly abandoned the whole idea of writing in Word. For one, it means jumping back and forth in a VM. Most Kindle books do not actually have so much formatting that you’re really getting that much benefit out of working in a word processor program like Word anyway. But more importantly, Word was just making me crazy with all that extra markup and styling. Furthermore, it was destroying my code formatting. I’d have a line of code with 4 spaces of indenting. It would sometimes do 3 spaces, sometimes 4, sometimes 5! No lie. True story. Trust me, I spent a couple of hours trying to just get a consistent 4 spaces = 4 spaces conversion. No go.

So I decided to just write my book in Sublime Text 2. Plain text baby!

OK, to be honest, it’s not plain text, but plain HTML. Yes, I’m writing my book with HTML markup. Before you start groaning, let me re-iterate that there is very little formatting that needs to go on in a Kindle book. Really all I’m doing is putting p tags around my paragraphs, and h tags around headings. And the occasional bold/italic/code/pre tag here and there. And images, yeah. But honestly, 95% of it is p’s and h’s.

I’d like to figure out some way to make that a bit cleaner eventually. Maybe some kind of markdown to HTML conversion. Something to research…

See my update on using markdown and pandoc here:

Anyway, I’m writing the code for the book in Sublime, so it’s nice to have the text and the code in one project so I can just copy and paste.

Now, the workflow in most of the examples I read was something like this:

1. Write.
2. Open MobiPocket Creator.
3. Import your files.
4. Tweak the following settings…
5. Export your book.
6. Close MobiPocket Creator.
7. Open an ebook previewer.
8. Load your exported book into the previewer.

Here’s the workflow I wanted to have:

1. Write.
2. Press F7.

And I have achieved exactly that! Yes, from within Sublime Text 2, I can change some text, hit F7, sit back, and in within a few seconds, I have an ebook reader open with my published .mobi format book loaded up.

The Setup

In the root project folder I have the following:

– book
– code
– images

book is a folder containing the chapter HTML files, plus a header and footer.
code is a folder with HTML and .js files that are the example code files I’m building throughout the book.
images is a folder. Guess what’s in it.
build.xml is an ant build file. What? You hate ant? Sorry to hear that. You lose. 🙂

Anyway, if you really don’t like ant, what I have is not rocket science. Should be easy enough to convert into your superior build system. But let’s look at what it does.

<project default="preview">
            code:    executes code_file property in browser
            publish: creates ebook
            preview: creates and previews ebook
    <property name="browser" location="/usr/bin/google-chrome"/>
    <property name="code_file" location="code/sierpinski.html"/>

    <property name="book_name" value="playing_with_chaos"/>
    <property name="author" value="Keith Peters"/>
    <property name="cover_img" value="images/cover.jpg"/>

    <property name="html_file" value="${book_name}.html"/>
    <property name="mobi_file" value="${book_name}.mobi"/>
    <property name="meta_file" value="${book_name}.opf"/>
    <target name="concat">
        <concat destfile="${html_file}">
            <filelist dir="book">
                <file name="header.html"/>
                <file name="pwc_ch01.html"/>
                <file name="pwc_ch02.html"/>
                <file name="footer.html"/>

    <target name="publish" depends="concat">
        <exec executable="ebook-convert">
            <arg value="${html_file}"/>
            <arg value="${mobi_file}"/>
            <arg value="--chapter=//h:h1"/>
            <arg value="--chapter-mark=pagebreak"/>
            <arg value="--level1-toc=//h:h1"/>
            <arg value="--level2-toc=//h:h3"/>
            <arg value="--authors=${author}"/>
            <arg value="--cover=${cover_img}"/>
            <arg value="--output-profile=kindle"/>
            <arg value="--smarten-punctuation"/>

    <target name="preview" depends="publish">
        <exec executable="ebook-viewer" spawn="true">
            <arg value="${mobi_file}"/>

    <target name="code">
        <exec executable="${browser}">
            <arg value="${code_file}"/>


We start out with some various properties that will get used throughout the build targets. The default target is preview while I’m writing the book, or code while I’m writing code. The preview target depends on publish, which depends on concat. The concat file takes all the chapters, wrapping them in an HTML header and footer, creating one large HTML file with the whole book. The header.html looks like this:

	  <title>Playing with Chaos</title>
	  <meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
	  <style type="text/css">
	    p {
	      margin-bottom: 10pt;
	    h1 {
	    	margin-top: 120px;
	    	margin-bottom: 20px;
	    	text-align: center;
	    pre {
	    	font-size: 10px;
	    .fig {
	    	font-style: italic;
	    	font-size: 10px;

And the footer just closes things up:


All the chapter files just go in the body section. Chapter 1 looks like this:

<a name="start"></a>
<h1>Chapter 1: Introduction</h1>
<h3>Fractals, Strange Attractors and Chaos Theory</h3>

<p>Blah blah blah</p>

<p>and blah.</p>

<h3>Another Section</h3>

<p>more blah</p>

<p>Here's some code:</p>

function foo() {

The <a name=”start”></a> is a special tag that Kindle will use to indicate the start of the book. If a user navigates “Go to… Beginning”, this is where they will wind up. So that’s only in Chapter 1. Chapter titles are h1. Sections are h3. Paragraphs are in p’s. Code blocks in pre’s. Note that any < or > in code (or anywhere for that matter) will need to be converted to HTML entities. Pain in the neck there, but whatever. To be honest, it’s less work than I had to manually do to format this blog post. Finally, there’s a custom Kindle tag that inserts a page break, useful for end of chapters.

Again, see the update at No manual HTML needed at this point with markdown.

OK, back to the build. After concat, publish runs. Let’s look at that again…

    <target name="publish" depends="concat">
        <exec executable="ebook-convert">
            <arg value="${html_file}"/>
            <arg value="${mobi_file}"/>
            <arg value="--chapter=//h:h1"/>
            <arg value="--chapter-mark=pagebreak"/>
            <arg value="--level1-toc=//h:h1"/>
            <arg value="--level2-toc=//h:h3"/>
            <arg value="--authors=${author}"/>
            <arg value="--cover=${cover_img}"/>
            <arg value="--output-profile=kindle"/>
            <arg value="--smarten-punctuation"/>

This calls up the Calibre command line tool, ebook-convert. The command line tools should be automatically installed when you install Calibre on Windows or Linux. Apparently there is one extra step to install them on Mac. The first two args are the input HTML file, and the output .mobi file. Then there are a whole bunch of options.

I’m saying chapters are h1’s and should get a page break. I’m not sure how that differs from the custom pagebreak tag I added manually, but doing both doesn’t seem to hurt anything. The table of contents should be built from h1’s and h3’s.

I’m setting metadata for the author name and cover image. The metadata for the book title will come from the HTML title tag.

I’m setting the output profile as Kindle. Not sure exactly what this does. Seems to work fine without it, but seems sensible to set it.

The last arg is –smarten-punctuation. This turns regular apostrophes, single quotes, and double quotes to their curly equivalents. So I can simply type


and get


in the output. Also converts single dashes to en dashes and double dashes to em dashes. Brilliantly, this option ignores anything in pre tags!

Once the book is published, the preview target will run. This runs another Calibre command line tool, ebook-viewer, passing in the name of the .mobi file that was just created. This pops open an ebook reader with your book preloaded. This is NOT a Kindle simulator by any means, but it will let you verify that your cover is set, your text looks like what it should, images show up, TOC works, etc.

So again, write something, throw some tags around it, hit F7 and there it is in ebook form. Couldn’t be better. You can then take this compiled .mobi and upload it to Amazon for publishing.

Additional testing. If I’m doing something that I want to make sure looks just right, I have a VM open with Windows running in it. There is a Kindle preview tool that you can download from Amazon that lets you preview how your .mobi will look in a regular Kindle, Kindle DX, Kindle Fire, iPad, iPhone, etc. On Windows and Mac you can also install the Kindle Desktop Reader and make sure your book looks OK there too.

Finally, nothing beats dragging the .mobi into right into a real live Kindle and seeing how it looks on the real live device. There’s actually a Calibre command line tool for transferring a file to a device as well. But with the Kindle, it needs to be plugged in and mounted for transfer, then unmounted to actually read the book. And I don’t test on device every time I build, so I did not make that part of my process.

Here’s the book as seen on a real device:

Oh, and there’s also the code target, which simply launches the specified HTML file in the browser. I just change the default target to code while I’m coding up an example, and back to preview when I’m writing the book.


Overall, I’m super happy with how this is working out. The big things I’d like to improve are 1. as mentioned, figuring out some possible markdown conversion to simplify formatting and 2. something to possibly automate replacing angle brackets in pre code tags.

Here’s a link to the Calibre command line tools:

And all the possible options for publishing HTML -> MOBI:

I’ve pored over that last link, but I’m sure there’s still some things I could use in there that I haven’t investigated.

10 responses so far

Playing With Chaos: The Book

Apr 29 2012 Published by under General, JavaScript, Kindle, Technology

Well, the title gives it away, so I just need to elaborate. I had so much fun and did so much research and wrote so much code for my Playing With Chaos presentation, and it went over so well and was very popular. But in the 45 minutes I had last week, or even in a full hour of talking, you can barely scratch the surface of the simplest bits of math or code and only show a few quick images or demos of each example. And there were lots of other examples that I didn’t even have time to touch on. I would love to be able to cover all the topics I had in mind, and go over each one fully enough, with well explained code. Thus, I’ve been thinking of writing a book based on the presentation.

The truth is that I’ve been thinking of writing this book for about a year. But doing the presentation at Beyond Tellerand – Play! solidified the idea. Here are some details about my plans:

1. I’m going to self-publish the book. I’ve been really interested in self-publishing for a while. This will be an experiment to see how well it works for me. The biggest thing I’m concerned about is the editing process. I’m sure I can dig up a technical reviewer or two, but the copy editing phase where someone at the publisher fixes all your spelling and grammar and unifies your tenses and persons and numbers, etc. is invaluable. I actually do understand grammar pretty well, but in a longer piece of writing I can lose track of the style I’m using and jump back and forth. It will take an extra reading or two with extra attention on this stuff to get it down. Or perhaps I’ll find someone willing to help me out on this point.

2. I’ll be going through the Amazon Kindle publishing service. I think this offers the best form of distribution, discoverability, protection, commerce, etc. In addition to being able to read the book on any existing Kindle, it can be read on any iOS, Android, Windows Phone 7 or Blackberry device and on any computer via standalone reader apps or the Kindle web app. This also allows me the option to publish through other services such as B&N Nook and Apple iBooks as well. In addition, there are services that will publish hard copies of your Kindle book on demand for those who want to kill trees. 🙂

3. I will not be doing a Kickstarter project for the book. I don’t believe most books require any kind of start up capital. Unless you need to do some kind of heavy research, travel, or buy some expensive equipment, or quit your day job and write full time, there is really no up front cost. You sit down and write the book. The only thing I might need to pay out for would be a technical reviewer and/or copy editor, and that would be later and something I’m sure I can work out. I’ve contributed to funding two books over the last couple of years on Kickstarter and neither one of them has yet seen the light of day. It leaves the author in an odd position of being responsible to many people, but with no single person invested so heavily that they are going to bug him daily to meet deadlines. I’m not even sure there is any penalty if you get funded and never release the thing you were funded to do. Do the contributors eventually get their money back if nothing happens?

4. The examples will be done in JavaScript with HTML5’s Canvas. This may or may not be your favorite platform, but I feel like it offers appeal to the widest potential audience. Even if you’ve never done any serious JavaScript, you can fire up a text editor and browser and be coding and running HTML/JS in minutes, for a total cost of $0.00. If you’ve done any programming in any other language, JS is a piece of cake to pick up, and generally easy enough to convert into the language of your choice. Few other languages require so little monetary investment, so little setup for a coding environment across the boards, and such a low learning curve for the language itself.

5. Right now, the TOC stands at 12 chapters, but that could change and rearrange. Right now I’m most of the way through the introduction chapter and have been working on developing a base package that all the examples can use to prevent massive duplication of code. The goal is to not rely on any major third party libraries just as jQuery, etc., and not to create something so complex that it becomes a heavy dependency. Basically, it’s just some boiler plate to grab the canvas, 2d context, some properties like width and height, and various utility functions for commonly used operations.

So watch this space for various updates over the next few months. Maybe even some teaser images or live demos. I haven’t really got a solid deadline in mind, but roughly hoping to be done by the end of the summer.

10 responses so far

Kindle Fire First Impressions

Nov 16 2011 Published by under Kindle, Technology

I got my Kindle Fire last night and wanted to post some initial impressions of the device.

First of all, I love it. Great form factor, feels very solidly built, great display, does all that I need it to do. I could not put it down for more than 2 seconds last night. Take that as a 95% awesome. The rest of the stuff I say here will be in that 5% maybe not so awesome category, so read it with that in mind.

Two big caveats with this device.

One, do not buy a Kindle Fire expecting to get an Android tablet. I would not call this device an Android tablet. If you want or need an Android tablet, go out and buy an Android tablet. This is a Kindle tablet that happens to use a version of Android as its operating system. If you can’t let go of that expectation, you will have a hard time with this device.

Second, the Fire is every bit as tied to the Amazon ecosphere as the iPad is tied to the Apple ecosphere. Pretty much every top level navigation leads to an Amazon service – Kindle books, Kindle cloud music and mp3 store, Amazon video portal, Audible audio books, etc. I’m a fan of all those services. If you are too, you will be in heaven. If you’re not, you’re going to feel like you wandered into the wrong party. Of course, I’m sure what Amazon is hoping for is that people will become fans of those services when they get the device. And that’s probably a pretty good bet. When you click on the Videos tab and see thousands of movies and tv shows you can watch for “free” if you have a Prime membership, you’re going to be awfully tempted to fork over $79 a year for that.

There are a few things that detract slightly from the awesomeness of the device, in my eyes. A lot of it has to do with it not being a real AmazonAndroid tablet.

For one, there’s no standard home / launcher screen like you have in other Android devices. Instead you have a bookshelf metaphor. The top shelf is huge and holds the “carousel”. This is a history of all the books you’ve read, apps you’ve used, web pages you’ve looked at. Problem is, at this point it’s permanent. You read the latest teen vampire romance novel, it’s cover is going to be loud and large the next time you turn on your Fire. Guilty music addiction? Be careful, or everyone’s going to know that the last thing you listened to was Celine Dion. Same goes for web pages. Enough said. I’m sure eventually Amazon will allow us to edit those, or someone will figure out where that history is stored and how to edit it.

Lack of standard home / launch also means no widgets. Under the carousel, you can save other “favorites”, which can be apps, books, web pages, etc. But widgets have no place on this device.

There is only a single hardware user control on the device – a power button. All your standard Android controls – menu, back button, home button, search, are in a bottom bar that can sometimes be collapsed to give an app more screen space. Likewise, the volume controls are all in software, accessible through another settings menu in the top status bar. This is very much in line with the original Kindle philosophy, which is to make the device disappear when you are viewing content. I don’t hate it, but if you’re doing a lot of navigating and jumping around from app to app, it is noticeably slower.

Amazon’s app store is pretty good. Unfortunately, you don’t get the full app store on the Fire. Due to various hardware limitations and the fact that it’s built on a forked version of an earlier Android build, it looks like the Fire needs specifically built Fire apps. Sideloading is possible, but I’ve seen reports that this is a hit and miss situation, with some sideloaded apps working fine, and others crashing. Again, you have to think that this is not an Android tablet, but a Kindle fire and the apps it runs are not Android apps but Kindle apps.

Finally, in what I consider possibly the biggest oversight, there is no external storage on this device. It has 8GB internal storage, of which 6 something is available. For me, that’s just about the point where you can store a decent amount of things, but you DO have to pay attention to what’s on there and remove things you don’t think you’re going to need for a while.

Of course there’s lots of other things that people will complain about. No 3G, no camera or microphone, etc. I don’t miss any of those things and don’t really expect them on a device in this price range. And anyone arguing about whether this is or is not an “iPad Killer”, just shut up. You’re an idiot.


So it’s got some imperfections, but again, in my mind all the bad points fall into that 5% not awesome space. If you can accept it for what it is, and you like Amazon services, it’s an amazing device, especially considering the $199 price tag.

20 responses so far

Thoughts on eBook formats

Sep 18 2010 Published by under General, Kindle, Uncategorized

The traditional markets that have existed for hundreds or thousands of years are still struggling with this newfangled digital media stuff, trying to impose old world restrictions on it that just don’t work. I’m all for an author, musician, artist or programmer getting paid for their work. But DRM as it exists is doomed. Virtually all DRM is eventually cracked and it just becomes a race between the manufacturers creating more complex DRM and hackers breaking it, and lawyers and judges threatening jail terms and huge fines to people doing no more than they have for decades – sharing their albums and books. You know something is wrong when the word “sharing” becomes redefined to mean something synonymous with “criminality”.

The music industry has been dealing with this for a while longer than the book industry and are slowly coming around. For most of the songs on the iTunes music store, you can buy slightly more expensive DRM free versions. Many other on-line music retailers are following suit and offering DRM free songs. And it actually seems to be working. People keep buying them and the record companies and artists are making money. Removing DRM from music did not result in the total downfall of the recording industry.

I think the key points that made it work for music are:

1. Make it very easy to buy what you want. Easier and safer than searching some seedy “warez” site filled with malware and viruses.

2. Make it cheap. 99 cent songs, 9.99 albums are affordable. As cheap or cheaper than I used to buy my vinyl LPs 30 years ago!

3. Universal formats. Download a song and play it on virtually any device.

Eventually the publishing companies will come around on this stuff. They are on their way:

1. Make eBooks easy to buy. They are doing well on this. Between Amazon, B&N, and iBooks, you can easily find pretty much any book that is available in digital format. Yes, you can also find pirated, cracked books, or crack the DRM yourself, but it’s a pain in the neck. Much easier to buy.

2. Prices probably need to come down. A book at $12.99 or more makes searching for a pirated version just that much more attractive.

3. The fact that the Kindle has its own proprietary format that no other device can read, and the fact that the Kindle cannot read ePubs, DRMed or otherwise, is perhaps its worst “feature”. Amazon gets away with this for now because they have the biggest and best selection of books and the best, most popular dedicated reading device. Very similar to iTunes a few years ago. But I think eventually Amazon is going to need to adopt the ePub standard or allow and actively encourage other ebook manufacturers and publishers to use the AZW format, making it the de facto standard. However, I think and hope that eBook DRM will go the way of music DRM.

16 responses so far

Kindle vs. iPad redux

Sep 13 2010 Published by under Kindle

I know I’m fanning the flames here, but I thought it was a bit funny. Not hilarious, but cute. Of course, you could make a follow up ad that showed the woman trying to check her email or whatever…

12 responses so far

Kindle Font Sizes

Sep 09 2010 Published by under Kindle

Just for reference.

Comments are off for this post

Kindle 3: Under the microscope!

Sep 03 2010 Published by under General, Kindle, Technology, Uncategorized

Yeah, this took a while, but I finally got around to sticking my new toy under the ‘scope. To be honest, the differences between the Kindle 2 and the new version are amazingly apparent the first time you turn the thing on. The contrast is supposedly 50% better, but my eyes say it is many times better. When I look at my Kindle 2 now, it does indeed look like “wet newspaper” as one of my dear commenters said in my last Kindle post. 😉

Anyway, here are the closeups. In each case, the low res shots are approximately 25-26x and the high res ones are around 400x. I concentrated taking the same shots on the same images / words at the same size on both models. Note that all the images are links to full size images.

First, an image, a close up from one of the screensavers.

Kindle 2:

Kindle 3:

Pretty easy to see that the K3 is darker and crisper. But to the naked eye, I feel the effect is even more stunning. The screensaver photos themselves are rendered beautifully. I’d still like some new ones, but even as bored as I am with the, the first few times I saw them, I had to stare a while.

Now let’s zoom in on that eye, to 400x.

Kindle 2:

Kindle 3:

What you are seeing here are some gradient bands of gray values. What I notice here is that the various shades are noticeably different in the K3, and kind of muddled in the K2. Also, what seems to be happening in the K2 is that the microcapsules of E Ink are either spaced a bit further apart or somehow have some kind of dark border. They are very distinct from each other, whereas the K3 capsules seem closer together with less of a noticeable border. Thus, in the K2, the “white” areas still have so much dark border around them that the areas appear more gray than white, whereas in the K3, the white areas are more uniformly light. This is evident in several of the following pictures as well.

Here’s a closeup of one of the branches in the birds screensaver.


Kindle 3:

It also seems like in the K3, there is a bigger mix of smaller and larger capsules, resulting in what could be called a higher resolution.

Now, onto the important stuff, TEXT!
Kindle 2:

Kindle 3:

Mmm…. rich and dark.

Let’s zoom in on the rightmost vertical stroke of the letter “m”.

Kindle 2:

Kindle 3:

Now we’re talking! Here you can really see just how dark the black is, as well as how much whiter the white is.

And now the curve of the letter “e”.

Kindle 2:

Kindle 3:

Again, you can see the darkness and the uniformity of the blacks and whites. What’s interesting here is that the fuzziness of the K2 actually seems to result in some crude antialiasing, smoothing out the stairstep of the curve. I’m not sure what’s going on here. It’s obvious that the microcapsules themselves would be capable of a higher resolution. They are not what’s causing the “jaggies”. I guess it’s the underlying grid of charge-producing elements that is giving you that pixelation. See the below image and link:

Anyway, that’s all I have for now. Notice that I did not mention any products beginning with an “i”. Hopefully this will help avoid World War 4 starting on this blog, but unfortunately will also mean fewer hits. Controversy sells. 🙂

Oh, and in case you want to pick up one of those nifty USB microscopes, they ROCK! And only $60ish.

Veho VMS004 DELUXE USB Powered Microscope

19 responses so far

Kindle and iPad Displays: Up close and personal.

Aug 12 2010 Published by under General, iPhone, Kindle, Uncategorized

This really isn’t meant to be a contentious post. It really only came about because I got a new toy, something I’ve been wanting to get for a while – a USB microsope! Here’s the model I got:

Veho VMS004 DELUXE USB Powered Microscope

The family had great fun playing with it tonight – looking at everyone’s skin and hair and dirty fingernails and bug bites, and paper and money and cloth and salt and sugar, etc. I could barely pry my daughter away from it. The software allows you to capture images and videos and even notate them with actual measurements, etc. based on the level of magnification.

While playing a bit more with it, I held it up to my computer screen and my Nexus One screen and could clearly see the pixels. Neat. Then I wondered what the Kindle’s screen looks like close up. Quite different! I then compared the Kindle’s screen at roughly 26x and 400x with the iPad’s screen at approximately the same resolution. Wow! No wonder the Kindle is so much easier to read!

First at about 26x.



And now at about 400x for the Kindle and 375x for the iPad.



The Kindle’s screen looks almost organic at high magnification. I need to learn more about eInk now. I will hopefully be getting my Kindle 3 in a couple of weeks (should ship August 27). I’m interested to see how that shows up – supposedly the contrast is much better. And now I need to get my hands on a iPhone 4 with that retina display. I’d love to see what that looks like close up. Not buying one though. Maybe someone at FiTC San Francisco will have one they can lend me for a photo.

[Update 8/13/10]

As requested, here are some additional photos at 26x and 400x, of print media.

First, newsprint, then a magazine, then a paperback book at 26x.




And now the same three, in the same order, at 400x:




Again, I leave it to you to make your conclusions.

[Edit #2]
I changed the post title to remove the “vs.”, replacing it with “and”. This is not a battle, people. Just some interesting photos. Relax. It’s all going to be OK.

428 responses so far

Older posts »