Brian Kernighan on the typesetting of "The Go Programming Language" book

A while ago, I bought the book “The Go Programming Language” written by Alan Donovan and Brian Kernighan. I have always been a fan of Brian Kernighan’s writings. I should admit that I bought the book mainly for his great examples and writings than for the Go language itself, but since then have got interested in the Go Language, after starting to read the book.

Perhaps every programmer knows Brian Kernighan as the “K” in the famous K&R book. He has also written a bunch of other great books, most of them are on my shelf, including some which are out of print. My other favourites are “Software tools” book and the “AWK programming language” book. Brian is also the “K” in “AWK” language.

Sure enough, the book does not disappoint at all. The way the language features are described and the “story” developed is something every programming language book author could try to emulate. One of the features of Prof. Kernighan’s books is that the first chapter is a tour of the language features and gives a good taste of the syntax of the language, leaving the readers with enough knowledge to mess around with the language and start writing complete programs.

The thing that stood out the most in my eyes was the outstanding quality of the type setting. Everything seemed just right.

Some (or most?) readers take typesetting of the programming books very seriously. There is this joke of Donald Knuth taking a break from the TAOCP book project to “invent” the TeX typesetting system.

One of the early goofups in typesetting is also incidentally in the K&R Book, written by Brian Kernighan, brought to my attention by my friend and colleague, Olve Maudal. A number of readers of the K&R C 2nd edition book believed that pointers and arrays are the same, due to the non-optimal pagination.

Okay, that aside, I emailed Prof. Kernighan about the tools he used to type set the book. There is a brief mention about it in the copyright page. But that didn’t satisfy me much. Here is what I wrote, on 28th Feb, 2016:

 Dear Prof. Kernighan,
 
 The Go programming language book is so beautifully typeset. To my eyes,
 it is more beautiful than those LaTeX based ones. But that's just my
 perception..
 
 Could you please say a few things about how your writing flow was and
 how you type set the book? I see the tools used in the copyright page.
 
 Thanks
 --
  Ramakrishnan

The reply came a few hours later on the same day. Reproduced here with permission from Prof. Kernighan.

 Hi, Ramakrishnan --
 
 Thanks for the kind words on the typography.  The core formatting
 is just troff (groff, really) with the -ms macro package.  We
 tried Latex briefly but neither Alan or I care for its output, and
 I personally find it impossible to control.  Troff is the devil I
 know -- it's ugly and irregular in many ways but it will put
 characters where you want them.
 
 The input was in XML, with a tag set of about 25 items for
 headings, paragraphs, index terms, program insertion, simple
 tables, and the like.  A Go program converted this either into
 HTML for rapid viewing on the screen and potentially for an e-book
 version, or into troff for printing.  Using XML was a mild
 nuisance when writing but the error checking was very helpful.
 
 We wrote a variety of small Go programs and scripts to fix things
 up, including one that rewrites troff output to do vertical
 justification so all pages are the same height.  There is also
 some fiddling with the generated postscript to put on printer's
 marks.
 
 The fonts are Alan's choice, the result of a lot of work on his
 part to find them and get the right sizes and appearances.  The
 handful of Asian characters were tough to get right; troff doesn't
 do wide Unicode characters properly, and there are a few places
 where we rewrote text to hide that fact.
 
 The drawings are all Alan's work, using Google's drawing program.
 We toyed briefly with using pic but it wasn't really up to the
 job, and it would not have worked with HTML without a lot of work.
 We avoided mathematics beyond superscripts, and the tables are
 pretty limited; eqn and tbl would have been ok but again would not
 have dealt with HTML.
 
 We should probably write a more organized description of what we
 did and make the tools available, though I think most readers are
 less interested in the process than you (and I) are.  The other
 thing is that although one starts with grand ideas of being clean
 and orderly, by the end the process is somewhat of a mess, with
 a complicated makefile to keep it running.
 
 Thanks again for writing.
 
 Brian

The last sentence certainly holds true for just about any project, as far as my experience goes.

"...although one starts with grand ideas of being clean
 and orderly, by the end the process is somewhat of a mess, with
 a complicated makefile to keep it running."

In a subsequent email, Prof. Kernighan added that the problem with Unicode was not much of an input problem and was because of troubles getting suitable fonts for actual printing.