October 13, 2010 at 3:45 PM by Dr. Drang
I got this book a couple of weeks ago through an interlibrary loan and was struck by how much it looks like what it is: an engineering book published in the ’70s.
I showed it to a friend who’s about the same age as me and asked him when he thought it was published. Without a moment’s hesitation, he said “Late ’70s,” which was dead on (©1979). We both have several books on our shelves that have this look.
I don’t have the design vocabulary to identify what it is about the book that made us so certain of its vintage. I’m sure the font plays a big role, even though most of my ’70s textbooks use a sans-serif font. The size of the title text must also be a factor, as well as the non sequitur image taken from the book’s interior.
And speaking of the book’s interior, here’s something you don’t see anymore:
That’s typewritten text, children, something you may have only read about. Books like this, destined for small sales, were produced through something called camera-ready copy. The authors were sent a stack of paper with light blue lines defining the margins.
The copy was typed within the margins and sent off to the publisher. The sheets were photographed and printing plates made directly from the photos. No real editing or book design—other than the cool cover, of course.
This inexpensive method of generating technical books persisted at least into the ’80s. When I was a young faculty member, two of my older colleagues had agreed to put together a book on certain computational techniques and several members of the department, including me, were contributing chapters/articles for it. The department was Mac-centric at the time and our word processor was Microsoft Word 3.
Word 3 was Microsoft’s second generation word processor for the Mac. The Word 1.x line ended at version 1.5, and there was no 2.x line. According to the folks from Redmond, the new Word was such a tremendous improvement that a single-digit increase in the version number wasn’t sufficient to express its awesome power. So after 1.5 came 3.0.
And, no question, Word 3 came with a footlong list of new features. It would have been a great program if they’d all worked.
The computational techniques book was the first time any of us had tried to use Word for camera-ready copy. It seemed like it was going to be simple: print out our drafts on normal paper with normal margins, then make the margins narrower to match the camera-ready sheets when we were ready to print the final copies. I think the plan was to print the finals on regular paper, cut off the margins, then paste (literally) them down onto the camera-ready paper.
Everything was going well until we had to change the margins. Word hated narrow margins and started behaving unpredictably. I don’t remember the specific numbers, but you could set the margins down to some value (say 0.6 inches) and the document would print as specified. Go any lower than that (say 0.59 inches), and the margins would be wildly different. Worse, there seemed to be no relation between what you specified and what got printed; set the margin to 0.59. 0.58, and 0.57 in turn, and you’d get printed margins all over the map.
This was disconcerting, to say the least. Writing the damned chapters was supposed to be the hard part; printing was supposed to be trivial. Eventually, one of the graduate students found, through trial and error, a set of margins1 that gave us printouts that fit the blue lines. He became the hero of the department.
It wasn’t long before I began hearing of other problems with Word 3. To many users, it was “Microsoft Weird,” a program to be avoided at all costs. I soon dropped it in favor of WriteNow, the word processor from NeXT whose feature list wasn’t nearly so long but was solid on the features it had.
It was about ten years later, when I switched to Linux, that I gave up on word processors altogether and began writing exclusively in text files. Troff and LaTeX may take some getting used to, but they always put the margins where you tell them.
Even though the right and left margins were supposed to be the same, you had to enter different values to get them to print that way. I seem to recall that one of the specified values was negative, but I don’t trust that memory. It couldn’t have been that bad, could it? ↩