I really don't think you can blame Amazon for the high prices of ebooks. From the publisher's perspective, ebook prices are disastrously low.

There does seem to be quite a bit of inconsistency on the part of the publishers, though. They complain that ebooks are destroying their business models, and then restrict Amazon and other retailers to charge comparable prices for ebooks, but they don't treat ebooks comparably themselves. Ignoring the fact that releasing an ebook doesn't require physical printing and the multitude of material and labor costs associated with that, they don't seem to apply the same editorial (and typographic) effort that they do with printed books.

Yeah, the publishers are mourning the loss of "hardcover edition" in the ebook format. That's where they make their mint.

I'm hoping that they will try (and catch on) a ebook+hardcover release model. After all, people buy hardcover either (a) because they need the product now and can't wait for paperback (or there isn't one), or (b) because they also want to show it off in their personal library. The ebook+paperback could offer that experience. Hardcover $30, Hardcover+ebook $33. That's $3 for free. Oh, hmm, looks like O'Reilly is already is doing this bit :-)

A month after each new release, you make paperback and ebook available simultaneously, offering the ebook at minus publishing and shipping costs. ($5 paperback, $3 ebook?)

    "Almost half the kindle ebooks I buy are formatted so
    poorly I can't (sic) read them."

Honestly? I think the typesetting is quite awful too but it has not interfered with my ability to parse the words on the screen.

I really wish that the typesetting was better but I am not sure if this is something that we will see any time soon. Can you imagine running latex on the kindle cpu everytime you flipped a page? On the other hand the ebook files would be huge if you prerendering all of the pages. You would have to prerender a separate page starting at every "location" and in each font size. That is an enormous number of combinations.

For me the major flaw is the lack of use of vector graphics in some cases. I have a number of technical Kindle books which attempt to use fixed-sized images for equations and they become so pixelated that they are completely unreadable.

As others have already pointed out, you don't need to compile from Latex on the device. The formats already have support for passable typography. Publishers aren't making an effort to use it.

I haven't used a recent Kindle, but the original eInk screens were slow enough that the tablet most certainly could have run TeX on the next page in the time it took to clear the screen.

Do you have benchmarks for running a tex engine on a tablet CPU? Everytime this topic comes upo on comp.tex the consensus seems to be that tablets are not yet capable of running tex on the fly.

The core of TeX is fast enough for any modern hardware, even tablets. For example, my laptop can compile the 494 page TeXbook (http://www.ctan.org/pkg/texbook) in about half a second.

What slows TeX down is that many packages use extremely elaborate abstractions, which all need to be evaluated using string expansion. These days you shouldn't be surprised if some package is using floating point emulation with TeX macros (https://github.com/latex3/svn-mirror/blob/master/l3kernel/l3...) behind your back. Handy yes, but certainly not fast.

Are tablet CPUs fast enough?

Probably not for a whole book, but for a single chapter? Almost certainly. And if you eschew the features of XeTeX or LuaTeX and just stick with pdfTeX, things could be very quick: For the example I posted elsewhere in this thread of typesetting a novel in 30s with XeLaTeX, pdfTeX does it in about 6s. A single chapter (32k of text): 0.8s, and I/O bound at that. Even if a tablet's 800Mhz Cortex A8 does that 5 times slower than my Core 2, it's fast enough to be done speculatively. It's certainly no slower than loading a web page over the internet.

Is the single chapter time with all of the modern typographic features the main article is about or without them (pdftex)?

For the single chapter test, the book was stored with each chapter in a separate tex file. All but one of the \input statements was commented out, but the preamble stayed the same as in the previous test: pdfLaTeX with microtype, memoir class, but no fontspec. The output was 25 pages. Enabling SyncTeX gives about a 30% slowdown in wall time, but only about 10% slowdown in CPU time.

(For comparison, when run on the slowest CPU I have handy, a 1.5Ghz Athlon XP, the single chapter takes 1.5s wall time and 1.1s CPU time.)

What effect would the extra required processing over the course of an entire book have on battery life of the device?

Except that the calculations need to be done before the eInk rendering even begins. If you were just saying that the difference between 1s and 1.5s is less than between 0.1s and 0.6s then sure, but I would argue that once you are above a certain threshhold making it even slower is even more annoying and they should do anything they can to shave off whatever ms they can.

Why, you can generate the next and next-next pages while reading the current one, right?

Footnotes moved to the end of the book.

Illustrations missing or put together in a block in the middle of the book.

Tables converted into justified text,equations missing, source code reflowed into an obsfurcated paragraph