Software problems with Kindle Fire as ebook reader

We've acquired a Kindle Fire. I've been trying it out. I like the screen. The size is slightly too large to be comfortable in a front pants pocket, but I could imagine keeping it there. I think it's a pretty nice tablet. Web browsing speed is decent. Video playing is good. Scrolling through moon maps works well. But it is a Kindle, after all, so one would expect its core functionality would be reading Kindle books. And that doesn't work so well. Here are a few problems, though maybe I just haven't figured things out. The good news is that all of these are software issues and hence Amazon can fix them if they want to. Moreover, third-party ebook reader apps will fix some of these, but they won't read the Kindle books.

1. No global search. One of the cool things about the eink Kindles is supposed to be indexed global text searching, so you can search through all your books at once, fast. No such thing. There is a search button when you go to Books, but it just searches titles and authors (and maybe some other meta-data). It doesn't look inside books. (And, yes, it's had plenty of time to index at least the dictionary that's there.

2. Super slow search within a book. Searching is the big advantage of an ebook reader over physical books. Without searching, an ebook reader is mainly a matter of convenience. With searching you can do new and intellectually useful things with your books. The eink Kindles (I am now tempted to say "real Kindles") index books and have super-fast searching within them. While the Fire does search within a book, it's super slow. For instance, I did my usual benchmark search for "junk" in my Kindle version of Aquinas's Summa. For comparison, on my aging Palm TX with Plucker, the search takes about 45 seconds. On the Fire it took about 4 minutes 35 seconds. The Fire is on a dual-core 1GHz device. The Palm TX is a 300MHz device, and the search is not index-accelerated. Without indexing, a decent developer should be able to get under a 30 second search time, and with indexing it should be instant.

3. Inconvenient installation of books not from Amazon. I tried to download my etext of the Summa from the Internet. It's in the proper .mobi format. Amazon's web browser duly saved it but did not recognize the .mobi extension, and offered to open it in QuickOffice rather than the Kindle reader. To open it in the Kindle reader, I had to move it to the Books folder. One could do that with a file manager app (I don't think one is included), but I just did it via a USB connection to a laptop. Then it opened fine. But why doesn't the Kindle's browser recognize Kindle files?

4. The minimum screen backlight level is set too bright, making reading in a dark room not quite as comfortable as it could, and also not so great for astronomy. To give Amazon credit, it's not much too high, and it's a problem on most Android devices. This is a software problem--the hardware is quite capable of lower backlight levels. Fortunately, I'm almost finished a (non-free) app that fix this issue.  (I speculate that this is done in order to avoid customer service headaches from users who set their brightness too low and then don't know how to set it back.)  I love ebook reading with a backlit display, but I like the backlight to be dim.  Update: The 6.3 update greatly improves the minimum backlight level.

5. Text rendering in the Kindle ebook viewer app leaves colorful shadows around letters in portrait, reverse portrait and reverse landscape mode. (The same problem occurs in the regular Kindle app for other Android devices.) The problem doesn't seem to occur in other apps on the Fire. There are anecdotal reports of eyestrain, but I don't know if they are related. The cause of the issue is that for better text quality, Amazon enabled subpixel rendering in the ebook viewer. Subpixel rendering uses the red, green and blue rectangles that each pixel is striped into to increase the effective screen resolution.  But to do that, you need to know how the red, green and blue rectangles are arranged, and you need to change your rendering when the screen is rotated by the user.  Otherwise, you get colorful shadows, and you'd be much better off using gray-scale antialiasing.

However, the ebook reader app does subpixel rendering on the assumption of horizontal RGB ordering no matter how the screen is turned.  While the shadows are visible to the naked eye, I verified them under a microscope.  See the photos on the side (the slanted line is the pointer in the eyepiece).  Their assumption of horizontal RGB striping produces beautiful results in regular landscape mode (landscape with power button on right) where the assumption is correct.  Notice how nice the Landscape letters look with no color shadows.  But in all other modes, the results are terrible.  The worst of all is reversed landscape (landscape with power button on left): you can see a nasty red shadow on the left of the long vertical of the "h" and a nasty blue shadow on the right.  Portrait and reversed portrait aren't quite so terrible, but are pretty bad (and I think especially bad if you turn on night mode and look at white text on a black background).  You can see that the portrait and reversed portrait "h" has the red and green subpixels turned on and the blue subpixels muted on the left of the long vertical stroke, which results in an orange shadow.  This works perfectly in the landscape "h" where the darkened blue subpixel merges visually into the vertical and the red and green ones merge into the white beside it, and that was the assumption on which the font renderer was working.

Points 3, 4 and 5 are all easy fixes if Amazon only wants to.  The subpixel bug can be fixed by just turning off subpixel rendering--less than a minute's work for their developer.  The text will still be of great quality, as one can see in other apps.  The inconvenient sideloading of books is an easy fix, ten minutes' work for a developer, but I can see that Amazon might have commercial reasons for not doing it.  The minimum brightness is another minute's work for their developer.  A good search would take a bit longer.  I'm guessing about 15 hours of developer time to get a polished and fully debugged good search.  The cost of all of this would be miniscule to Amazon.