Hacker News Reader

Comment by avn2109 | Hacker News Reader

>> "Even ebooks need specialized design and typesetting"

I must confess to being baffled by all this talk of typesetting, for the following reasons:

1) My ebook readers (Calibre and iBooks, mostly) algorithmically render and reflow the text to arbitrary typefaces, sizes, columnar layouts, etc. Isn't this "typesetting?" And isn't it taking place entirely in software? [0]

2) Latex consumes a plain-text (aka neither designed nor typeset) file as input and produces tolerably-good machine typeset output. Its output is vastly better than plenty of well-regarded periodicals such as [1], which proves by construction that good-enough machine typesetting can be implemented.

[0] I'm not claiming iBooks typesetting is remotely comparable to what's found in a Random House hardcover, but rather that no hand typesetting at all takes place for most (all?) ebooks.

[1] http://www.cabinetmagazine.org/

View on HN

Your ebook readers get a lot of hints from the ebook file about how to present the material---I am light on details, but I believe them to be significant. It's true that there's no human there checking the typeblocks for rivers and orphans, but I can tell the difference between an ebook file produced by Calibre and one which a human has had a hand in, I happily pay my $13 for the latter, and woe betide the publisher when I discover that I paid $13 for an automated conversion. (The most egregious was a math book which OCR'd the formulas---from a book which was evidently set for print in LaTeX.)

When I'm translating plain text (Markdown-ish) input to LaTeX, I spend a bit of time going through by hand making sure all my formatting has converted correctly, any accents or non-roman characters are correct, the single- and double-quotes are correct, I haven't accidentally copy-pasted any ligatures, I have included hyphenation for nonstandard words, I've included any relevant non-breaking spaces, figures and headings and captions are flowing correctly, etc. etc. And all of these are still necessary when producing an ebook.

It's maddeningly detail-oriented, but the results are really noticeably much better, and in many cases make the difference between the text being readable and not. It's a bit like the cue dots at the movie theater---if you're not looking for them, you don't notice your uninterrupted experience unless the projectionist screws something up.

That's nice for a perfectionist. But how many readers care at all or could tell the difference if they tried? Do you struggle to read stories on the web because they're not hand typeset? I personally find that the content of a book completely dominates my experience over any of the superficial details. Well, I do use an annoying e-book reader that keeps accidentally turning pages for me and I lose my place. No amount of carefully placed hyphens will overcome that though, but a bit of software could.

Most of those issues I mention are exactly the kinds of issues which pull the reader out of the text, even though he may not be able to pinpoint exactly why. Certainly often when I use Instapaper to read a web page or Calibre to convert ebooks I can read through the issues if I try hard enough, but it takes more effort than reading a well-produced book, and I somewhat regularly give up on automatically-converted texts because the issues are just too dire.

(Some of my other favorite conversion errors: Endnotes or references not hyperlinked. Chapters and other headings not correctly marked-up. Page numbers or other irrelevant header/footer material not stripped. Footnotes, margin notes, or other relevant header/footer material stripped. ...As you can tell, I'm great fun at cocktail parties.)

That also applies to code, I've seen some ebooks that have blocks of code formatted like they exist on a blog instead of in a printed environment. It made reading them a pain because code snippets were word wrapped badly, split over multiple pages, and you'd get pages and pages of code.

Given that ebooks are electronic, perhaps they could use some sort of pop out window for larger code snippets, so that they could be scrolled rather than in page format.

LaTeX can only do typesetting when a human operator makes it happen. Human operators for LaTeX tend to be fairly expensive, I dare you to try and hire one.

Or could, oh, horrors, the authors, editors, and proofreaders learn to use LaTeX themselves so the typesetter could just check the final document for errors?

Division of labour tends to increase efficiency. Do you really want an author spending hours reading LaTeX tutorials, or do you want them to get on with their personal specialty and let a typesetting specialist do the typesetting? Either way the ultimate cost is going to be similar.

But the problem is that their personal specialty is not valued much, so if they want bread on their table they better augment it with a complementary specialty.

Hi, LaTeX copyeditor and typesetter here. The bane of my existence are authors who know just enough LaTeX to be dangerous. First, almost all of their formatting work is the first thing to be thrown out. Second, authors are strongly incentivized to learn the bare minimum of LaTeX to do what they need, and to copy-paste furiously whatever stuff they find on the net. You have to remember that (La)TeX is both a markup and a programming language. Can you imagine spending your time reading code written by a copy-paste monkey? I can, and don't wish you the pleasure.

This comment could so easily be PHP about instead of LaTeX, your pain is shared.

Sure - for highly specialized stuff. But, let's not pretend that 99% of the published work couldn't be well served by standard LaTeX templates and a little effort of learning the basics. If that is too much, then how do they send you the formatting specifications anyway? In some custom, poorly self-invented format?

LaTeX is fine for putting out pdfs. It's not a sufficient skillset for putting out an ebook in any other format. It is still a pain to put out a math-heavy book in a wide range of formats. I would say that Softcover (Michael Hartl's effort) is making that a lot easier, but I can't use the full range of LaTeX there (for reasons discussed elsewhere in this thread) and I still need to visually check every format to make sure that formulas are typesetting appropriately, because I'm trying to push the boundaries of current implementation -- and that's just in writing about probability and linear algebra.

In addition, if you really want to put out a quality product you have to be aware of how each e-reader renders the stuff you send them. Different e-readers process the same file differently and not all support the promised features of epub 3.0. It's best to know up front what each supports in terms of images and scaling, and then write with that in mind. Again, far beyond latex.

Reply on news.ycombinator.com