Hacker News Reader

Comment by dfc | Hacker News Reader

    "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.

View on HN

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

Reply on news.ycombinator.com