Let me clarify what I meant by that. Touchscreens built into the console of the car should be banned. Stand-alone GPS receivers are different, because you mount them in the corner of your windshield, so your peripheral vision is still on the road while you're looking at them.

In-dash GPS systems should be banned, both because they seem to universally suck and because using them to figure out where to turn is inherently less safe than using the ones mounted to your window, because you have to look down so far.

Of course, the absolute worst GPS systems are the in-car GPS systems that detect when you're moving and won't let you search or enter a destination location. That makes sense if the driver is operating it, but it basically makes them utterly useless if you have two people in the car and want to figure out where to stop for food (the single most common use of GPS devices, in my experience). Those should be banned because they encourage non-emergency stops on the side of the highway. :-)

Unless you mean the old e-ink Kindles (pre-KF8), that runs contrary to my experience. All the modern Kindle readers are based on WebKit, and WebKit's SVG support is generally very solid. What problems are you seeing?

Yeah, a rate of 1.1 hyphenated words per thousand isn't excessive at all. I grepped my own fiction writing, and determined that I average about four hyphenated words per thousand in fiction, or almost two per average printed page by your metric. One every 2.25 pages is nothing. :-)

So unless there is something more to the licensing terms than you're suggesting, there shouldn't be any problem with creating your content in an open format, and then using KindleGen to generate the content for the Amazon store.

At issue is the fact that Kindle readers can only side-load content in MOBI format (plus non-reflowable horrors), and MOBI-format files can only (usefully) be produced by KindleGen. So the fact that you can sell the content in open formats through other stores is mostly irrelevant; you can't sell the content in open formats to Kindle users because they can't side-load an EPUB, and you can't sell the content in MOBI format because the license for the tool that trivially translates your source files into MOBI files won't let you resell those MOBI files outside Amazon's stores.

So short of you selling it in an open format and telling your users to run a command-line tool, or telling them to install Java and then install Kindle Previewer (which, among other things, provides a crude GUI for KindleGen), what you're advocating isn't a realistic solution.

With that said, Amazon's licensing changes annoyed me enough that I've seriously considered making the Kindle edition of my books available "free for registered EPUB users", so that users submit a web form and provide a copy of the EPUB book obtained from any EPUB store, and a script on the server verifies it and emails them a free copy of the MOBI book, thus effectively selling the MOBI book through every other online store, while still strictly complying with the terms of Amazon's license by only using it "to format works to be distributed at no charge". But although that would be easy for me to do, that's the sort of thing that 99% of writers out there couldn't pull off.

Well, yeah, in this case. But Amazon doesn't generally make it a point to edit books for people. The assumption is that the Kindle MOBI file isn't the original source content, so if Amazon were to monkey with the MOBI data, their changes would just get stomped on the next time the author fixes anything. For Amazon to fix this in a way that would have any permanence, they'd have to add that script as part of kindlegen, and then it would break millions of other books. Better for them to ask the author to fix his or her source content and rebuild the derived MOBI.

Auto-hyphenation is built into WebKit, so unless they took steps to deliberately break it, it should work in all readers based on WebKit. To my knowledge:

• iBooks supports it (in iOS 6 and later, and all versions of OS X)
• Kindle previewer supports it in all the KF8 modes which should mean newer Kindle readers support it unless somebody at Amazon screwed up pretty carelessly (e.g. by failing to copy the hyphenation dictionaries into the right places while building the firmware images).

I was not aware of Nook supporting it. That's surprising, given that they're based on RMSDK. Hmm. Upon digging further, RMSDK egregiously violates the CSS specification by using "adobe" as a vendor prefix, then proceeds to also use the wrong CSS property name, resulting in the property "adobe-hyphenate" instead of "-adobe-hyphens" as it should be, with values of "none", "explicit", and "auto" instead of "none", "manual", and "auto". Nice, job, Adobe.... [redacted swearing at what feels like the hundredth instance of Adobe flagrantly violating the CSS specification that I've run into personally]

I think you have that backwards. If you have fewer than 6 holes, it didn't originate in California. If you have fewer than 10, it didn't originate in NYC. If you have fewer than a hundred or if the hubcaps are still intact, it didn't originate in East St. Louis.

Why don't eBook publishers use a typesetting system based on TeX or LaTeX?

Let me count the reasons.

• Books in electronic form must be reflowable, to accommodate variations in device size, and to accommodate rotation. What this means is that page numbers can change continuously. If I rotate a reader from portrait to landscape mode, then flip to the next page, then rotate it back into portrait orientation, there's no guarantee that the page boundaries are the same as they were in portrait orientation previously. So imagine having to run LaTeX on your entire document more than once per second, with a page offset, rendering only a subset of the content.
• Books in electronic form require the ability to reliably link between documents. Good luck with that in LaTeX, much less in a hypothetical reflowing LaTeX.
• LaTeX's font handling and Unicode glyph handling are dreadfully subpar even in XeLaTeX. Line breaks around em dashes and en dashes are as broken as they were in OS 9, requiring use of \hspace{0.001pt} after them if you want LaTeX to wrap correctly.
• LaTeX is, IMO, terrible for anything that involves even basic custom formatting. I've used it for fiction book publishing. I have over 2,400 lines of custom LaTeX macros to prove it. By contrast, even when working around the quirks of multiple EPUB readers, I have only about 1,000 lines of simple CSS that gives almost exactly the same results as those 2,400 lines of seriously complex macro code in LaTeX. To be fair, there's a bit of Perl content translation code that replaces a little bit of macro code, so the difference isn't quite as extreme as it sounds, but it's a lot easier to do math computation in Perl than in LaTeX macro code, and a good chunk of that math was only required because LaTeX lacks some fairly basic formatting functionality, such as an equivalent for the CSS min-width property. LaTeX is positively primitive when compared with HTML and CSS, IMO.
• LaTeX is a write-only language. Like Tom Christenson said about Perl, nothing can parse LaTeX other than LaTeX. It is basically impossible to properly translate LaTeX into any other form, which makes it a terrible source language. Most people writing content want to write once and reuse in different formats, so you're better off starting in a proper semantic markup language like XML. And if you're starting from XML, it's easy to spit out HTML. It is butt ugly to spit out LaTeX. Been there, done that. I have almost 800 lines of custom XSL on top of the existing DocBook2XML code to prove it.

There are probably many more reasons I could think of if I took the time, but that's just what comes to mind off the top of my head. Knowing what I know now, if I had to do my latest project over again, I would have written a custom typesetter in JavaScript that runs in a custom WebKit-based app. It would have been faster, and I would have had more control. I can't even imagine trying to use LaTeX in an eBook reader. It would be like printing a book using a million Chinese workers with quill pens.

What math and CS book publishers should be doing is formatting formulas using LaTeX and converting the PDFs to SVG images. That should give you nicely formatted formulas whose text is still searchable. The rest of the content should be HTML, just like any other eBook. It isn't rocket science; the publishers you've dealt with just don't care about those books enough to do the job correctly. :-)

Amazon isn't your host.

It's your printer and publisher --- and both have always had a say in grammar, style and formatting.

Uh, no. Amazon isn't a printer or publisher in any meaningful sense of the word. Many eBooks distributed by Amazon have an actual publisher associated with them, and for their print editions, have an actual printer, too. Amazon is more properly described as a distributor and a bookseller. Traditionally, neither has had any say in grammar, style, or formatting; their sole recourse is to refuse to carry a title that they feel is of insufficient quality, which is what Amazon does.

The real problem with Amazon is that they also exercise monopolistic control over what can be read by Kindle readers, by not publishing the details of their file format and by disallowing the use of their publishing tools to create content for sale through any means other than their own online store. It is the electronic equivalent of the only bookstore chain in an entire country requiring you to use a nonstandard set of book dimensions and requiring that you exclusively sell any books with those dimensions through their store (in perpetuity). It is simply beyond insane, and the net effect is that Amazon can't simply tell people to distribute their junk books elsewhere, because people aren't allowed to do so. So instead of a nice curated collection, you end up with a steaming pile of crap.

The Kindle can load its ebooks from anywhere. Sure, it's perhaps easier/faster to get them straight from Amazon, but there are no technical barriers whatever to loading any file you want onto your Kindle.

Actually, there are technical barriers, and steep ones. Amazon does not use a standard eBook format, but rather uses its own custom binary blob. Because Amazon does not publish information about that format, there is exactly one tool that is known to generate this format in a guaranteed forward-compatible way. That tool, kindlegen, was written by Amazon, and the licensing terms from 2.0 onwards (the first version to support nontrivial formatting) do not allow you to use it for creating content that is sold outside Amazon's store. So in order to distribute content elsewhere, you have to either:

• give it away for free,
• violate Amazon's license,
• use an unauthorized tool that produces content based on reverse engineering, which may or may not be even remotely correct, or
• sell an EPUB book and require your readers to convert it to Kindle format themselves.

None of these choices is viable, IMO. As such, I consider Kindle to be by far the single most locked-down eBook reader on the market today. At least when Apple puts licensing terms like that into their book generation software, they have the decency to document the format so that you aren't forced to use their toolchain....

Conditioning has a lot of scientific basis. A psychotherapist talking about translating neuroscience to raising kids sounds suspicious.

Ah. What's news then, is that Amazon can't deploy a simple perl script to fix common typography errors such as these.

Please don't encourage Amazon to do that. Deciding whether a particular editorial choice is correct or not programmatically is a lot more complex than deciding whether video is likely to be unstable, and programmatically fixing those mistakes correctly in a pile of inconsistent, semi-random text and markup is dramatically harder than applying an IS algorithm to video.

In my experience, whenever Amazon attempts to "fix" content, it just causes more work for the 90% of content creators who know what we're doing, as we have to find ways to work around Amazon's ingestion scripts' brain damage. For example, if Amazon deployed a Perl script to "fix" this, then odds are good that mathematics texts would also get "fixed", and by "fixed", I of course mean broken.

The best way for Amazon to handle this is to do almost exactly what they did: wait for someone to report a problem, examine the content to make sure the report isn't bogus, contact the content creator, and ask for a corrected edition. If the content creator responds by saying, "No, that's really what I meant," then let it go through. Anything else just gets in the way of everyone in a misguided attempt to help a small percentage of content submitters. And the number of people who are even capable of submitting a file with Unicode minus sign characters in place of hyphens is vanishingly small.

With that said, Amazon should have looked at the content more carefully and pointed out the Unicode minus signs, rather than saying "too many hyphens", which is just absurd; the hyphen count described here seems low to me by a factor of three or four, not high.

There is a unicode character known as a soft hyphen. The soft hyphen indicates where to break a word if it doesn't all fit on a line. This character should be used instead of a hard hyphen most of the time.

Too bad eBook readers are very inconsistent in their support for that. Some readers display an icon indicating an unknown glyph, many fail to insert the hyphen....

IMO, the best you can do is trust the reader's automatic hyphenation and hope for the best. To do so, in your stylesheet, add:

hyphens: auto;
-webkit-hyphens: auto;
-moz-hyphens: auto;
-o-hyphens: auto;

And set these to "manual" if you need to prevent hyphenation in certain spots (e.g. headings).

This. If I had my way, I would ban all touchscreen control systems in cars. They're fundamentally unsafe by design as long as there are humans behind the wheel. If it is unsafe for me to look down at my cell phone and read a text message, it's a hundred times as unsafe for me to look down at my radio, see what channel it is on, scroll through a list of channels, and choose the right one. It is almost as though someone at every auto company simultaneously thought to themselves, "We've been improving the road safety of our cars for three or four decades, and the lower accident rate has meant fewer replacement vehicles. What can we do to cause more car wrecks?"

If North Korea actually did it, it was a brilliant move. They've gotten the US, including the government, via the president, to whip itself into an impotent frenzy. Impotent? There's a fair chance that North Korea has nukes, they certainly have the ability to deliver them to several large cities in the region, and they have a large and powerful neighbour who won't take kindly to hostile military action on their borders because of some stupid movie. Nobody is going to be invading North Korea. So Kim gets to laugh as the US is forced to back down.

I don't think NK managed to engineer so much. Some independents hacked Sony and the US government saw it as a great opportunity to get a few Internet surveillance laws passed.