Most MSs ship with markup, which is then stripped out as part of flowing the manuscript into typeset pages. The typeset pages are then sent for proofreading against the requested markup. Is a verse extract set as such? A proofreader makes sure.

Moreover, she checks to ensure that common typesetting and pagination errors (widows, hyphen stacks, loose lines, too few lines below a head, a figure preceding its callout) have been avoided. Occasionally, the copy is changed to fix said problems. If the book is coming in overly long, and the length is not the fault of the book designer, then the copy will be hacked away at until it fits (there are printing budgets to stick to, after all). And even under the best of circumstances faulty copy will sneak all the way up to this rung of the bookmaking ladder—it needs to be marked, sent to typesetting, sent back to proof, and then OK’d. It is an impressively thorough, expensively fusty process.

Clearly: to fit your proposed standards, all editorial changes should be integrated into the initial MS, and any pagination should be set aside until all parties are completely satisfied with the digital book. Version control then becomes the problem. Will edits for length and typographical sturdiness be allowed? Then the hardcopy book becomes a pan-and-scan to epub’s letterbox. Will the physical typesetting be allowed to suffer in the name of fidelity to the copy? That hurts the book’s reputation as the more-beauteous (and therefore more premiumly-priceable) iteration of a text.

We’ll invent new beauties, most certainly, that aren’t dependent on trim sizes and the like. Or: we’ll accept that paper is costly and pixels are not, so let the page count swell and damn the cost of printing a perfect thing. A certain class of consumer will learn to pay for that perfection.

I don’t actually know of anyone who read this blog that uses LaTeX (the joys of which I have blogged of in the past), but after spending way too much time today trying to figure out how to use XeTeX, which lets you use Mac OS X’s built-in fonts with LaTeX, I figured I’d post my really, really simple results here.

I use a slightly extended version of his example (I use mathspec instead of fontspec) in my drangreport file, but this was the post that got the ball rolling. Custom fonts in LaTeX don’t have to be a world of pain.

From the Monotype Book of Information (1950)

Tex Live 2013 (2012 is frozen at the end of this month) should have just one typesetting tool — XeTeX. XeTeX outputs directly to pdf in one step, it is by far the easiest tool to support for external products, its usage of unicode and integration with modern fonts would allow the ancient texmf to be dropped entirely, and with a little bit of development platex (japanese character support), could become unnecessary. With just one underlying typesetter to focus on, development of that typesetter would accelerate greatly and many packages would become obsolete, further freeing up time for purposeful TeX development.

When I first read this, I thought it was a knee jerk reaction, and would cause more problems than it solved. But I was still using pdflatex at the time; now I’m using XeTeX, I realise how nice it is to be able to embed any fonts in your document, and I imagine that there are other advantages. Maybe this isn’t such a bad idea after all.

Uses the cancel package. I think the label on the arrow is a bit big, but it’s useful to know.

Designer and programmer Jürg Lehni analyses the evolution of typographic technology and the nature of digital fonts, and introduces Donald E. Knuth’s groundbreaking TeX and Metafont systems. An essay complemented by interviews with Peter Biľak, Erik Spiekermann and Dimitri Bruni (NORM).

via https://twitter.com/#!/ariddell/status/195662554578690048

Not sure I agree with the headline assertation, but the article is rather interesting. “Digi Grotesk […] was designed for use in [Rudolph] Hell’s pioneering cathode ray typesetting machines …”

"The knitr package was designed to be a transparent engine for dynamic report generation with R, solve some long-standing problems in Sweave, and combine features in other add-on packages into one package (knitr ≈ Sweave + cacheSweave + pgfSweave + weaver + R2HTML::RweaveHTML + highlight::HighlightWeaveLatex + 0.2 * brew + 0.1 * SweaveListingUtils + more)."