Thursday, December 17, 2009

Finding a printer

Full disclosure
I purchase printing and binding services as an agent for my clients. I pass through the exact amount I am charged. I do not charge a markup or receive a commission. This is just a service I provide, at no cost, to help ensure that my publishing clients receive finished goods whose quality reflects all the hard work that went into designing them and get them at a fair price. So what follows does not reflect any financial interest on my part.

What is a high-quality book?
In discussions on various LinkedIn groups (and in other venues as well), I regularly see people with a variety of backgrounds endorsing the “high quality” of books produced by one printer or another, one subsidy press or another. These statements don’t mean a lot to me, because I don’t know how knowledgeable these individuals are about printing and binding production values.

I’ve had printing company reps proud of their companies’ work send me sample books that ranged from bad to godawful. So I have reason to suspect the judgment of authors who tout the great quality they got from a vendor.

I’m picky. Here are some of the things I look for.
  • I expect good backup. What does that mean? It means that if I hold a leaf of the book up to a light, the type on the back of the leaf should align with the type on the front. The left and right margins should be exactly even and the top line of type should be exactly even. I should not see the type on the back misaligned from the type on the front by even a millimeter.

  • I expect black ink to be black, not gray, and I expect it to be that same black throughout the book. The type should not vary in density from page to page or from the front of the book to the back. There should not be reflective glare from the type (seen when toner is applied improperly in digital printing).

  • If there are halftones, I expect good tonal range and contrast. If there is line art, I expect good sharpness.

  • I expect precise folding. What does that mean? It means that if I riffle the pages (like an animator’s flip book or like a deck of cards), the top margin should not waver up and down but should remain constant throughout the book. I’m not talking about pages where the margin is designed to be different, such as chapter pages. I’m just talking about the work of the folder operator.

  • I expect the book to be trimmed square and to size. The dimensions of the front cover should match the dimensions of the back cover and both should be within a very close tolerance of the design size.

  • I expect the cover (for a perfect bound book) to be properly aligned, with the spine centered, all live copy within the safety margin, and bleeds intact (no white showing).

  • I expect the cover to be glued properly, with no excess glue squeezed out and with the cover glued evenly onto the edge of the first and last pages. Looking at the top and bottom of the spine, I expect the glue layer to be even from the front to the back of the book and the top to the bottom.

  • I expect coatings and laminations to be applied properly, with no peeling or curling.

  • I expect a printer that services small publishers to screen submitted files for suitability and to advise customers when the files have significant problems (such as poorly prepared images or low-quality typesetting). “We print whatever the client sends us” is not an appropriate policy for companies serving the self-publishing market.

Four tiers of printers
There are roughly four tiers, in my mind, of book manufacturing:
  1. Non-specialists. These are printers for whom book manufacturing is an occasional job. The category includes the local Docutech center, accustomed to printing and binding documents that businesses distribute internally or to customers. It includes local job printers who send the printed pages out to a local custom bindery. It includes larger commercial printers who do that or perhaps have a small finishing department. It includes printers who solicit book business to fill holes in their schedule but really aren’t equipped for it; the shoddiness of their books is obvious.

  2. POD. The major players in the print-on-demand market are like talking dogs: it isn’t that they’re good at it; the remarkable thing is that they do it at all. For the most part, their employees do not come from the book manufacturing industry; they are trained on the job, and they measure their success by how fast and cheaply they can fill an order for a single book. Book quality is passable, and it meets the needs of the POD market.

  3. “Good” book manufacturers. This group includes many companies whose names are bandied about, with enthusiastic recommendations, on self-publishing mailing lists and websites. These are good, solid printers who produce acceptable books you might find on the shelves of any bookstore. Most people will be insensitive to defects. Problems I’ve seen include less-than-perfect backup, mediocre folding, some quality control issues in cover application, and—probably the biggest problem—a willingness to print completely unacceptable files. They are within ethical boundaries to simply print what’s sent to them. Nonetheless, if they are going to cater to amateurs, I think they should either push back when they receive garbage or they should fix the problems and charge for the service. At the very least, they should flag such jobs internally so that when someone like me asks for samples they refrain from sending out those books.

    Another feature of this group is that their digital short-run books and their offset books are easily told apart.

  4. “Excellent” book manufacturers. This group includes some of the largest book manufacturers in the country (as well as some smaller ones and some that are not in the country). While their bread-and-butter customers are large publishers, they are efficient enough that they can also happily serve the independent designer market (not sure how well they handle amateurs, though). Quality ranges from perfect to near-perfect, and only a technical examination can distinguish their offset work from their digital work. In my experience, prices in this category are actually lower than in the “good” category (I don’t know why, but I also don’t ask why).
That said, were I to have a job very different from past jobs, in terms of paper, page size, binding type, or quantity, I would certainly get bids from printers in both the “good” and “excellent” categories. It may be that one of the “good” printers has a sweet spot that enables it to come in with a low price. So far that hasn’t happened, but I’m not oblivious to the possibility.

Saturday, December 12, 2009

Interesting software QA test case

Hold those cynical thoughts for a minute. There really is such a thing as software quality assurance testing, an activity that employs a great many skilled and intelligent people. Despite the annoying flaws we users complain about in commercial software, it wouldn’t be on the market at all without the diligent and unsung work of QA departments everywhere.

Part of what QA departments do is a type of automated testing in which a script runs a piece of software through its paces, entering all sorts of rule-breaking text strings in input fields and seeing whether the software handles the rule-breaking gracefully. These test strings comprise all the weird cases analysts can think of—trying to type 100 characters into a field that is 30 characters long, using non-Latin characters into a field that expects Latin characters, typing letters into a number field, and so forth.

My serendipitous test case
My post yesterday is titled “<Redacted>.” Note that it begins and ends with angle brackets. Angle brackets have a special status in markup languages that derive from SGML, such as HTML, XHTML, and the others that the Web is built on. Angle brackets signal to the markup language interpreter that what is between them is a tag, information the software uses to decide, at the simplest level, how to display what follows (until a closing tag is encountered).

As a consequence of this special status, if I want you to see an angle bracket in the displayed text, I have to use a workaround. The workaround is to put in a character code (called an HTML entity) that will be interpreted as a mathematical less than or greater than symbol. Knowing this, what I typed into the Title field for yesterday’s post was &lt;Redacted&gt; (and I just applied a similar trick to make that come out right). So far so good.

But as you know, a blog post is more than a simple HTML web page. When I click the Publish Post button, my browser sends information to a server that triggers software to assign a URL-friendly name to the post and store what I’ve typed in a database. That database has rules for how text is stored. Other software extracts text from the database and sends an HTML page to your browser so you can read the post. Other software extracts the information in another way to supply your RSS feed reader. When you view my post, either as a web page on my domain or in your feed reader or in your email or…wherever, other software has intervened to process the text.

So there are lots of places where my angle brackets have to be interpreted and processed.

Complicating matters is that a lot of low-level text processing takes place inside software modules that are freely distributed to programmers. These modules may be written in a programming language different from that of the surrounding program, and the programmer who uses them may not fully understand all that goes on inside them. For example, if I want to build a web form that asks for a phone number, I may search around for a Javascript program that validates entries to assure they are legitimate phone numbers. I don’t have to know how that works; I only need to know how to use it.

Back to <Redacted>
Typically, Blogger creates a URL for blog posts based on the post title. It strips out punctuation and words such as a, an, the, and a few others. For example, my post titled “Do you have the willies?” became http://www.ampersandvirgule.com/2009/12/do-you-have-willies.html. For yesterday’s post, though, Blogger looked at the post title and threw up its hands (wise move), basing the post URL on the first line of the post body, instead: http://www.ampersandvirgule.com/2009/12/you-may-have-seen-story-other-day-about.html. So far so good.

But the post title gets reported in many other interfaces. It has variously shown up as:
  • <Redacted> [correct]
  • &lt;Redacted&gt; [user-unfriendly but not wrong]
  • Untitled Entry [uninformative, but a sign of recognition there was a problem]
  • [blank]
My humble suggestion to software QA professionals everywhere is that this is a test case they may want to add to their battery.

Friday, December 11, 2009

<Redacted>

You may have seen the story the other day about the US Transportation Security Administration manual that was posted on the agency’s website several months ago. It was a PDF in which sensitive material was blocked out with black rectangles placed over the text. If one has only a user’s eye view of software (if you’re a manager, in other words) and can’t be bothered learning anything about what the software does and how it works, this may seem like a reasonable way to secure the information. You can’t see it, so it isn’t there, right?

As Alexander Pope put it, “A little learning is a dangerous thing.”

The fact, as anyone who has bothered to learn anything about PDFs knows, is that the text was always there, merely covered, and the simple expedient of choosing the text selection tool in the Acrobat or Adobe Reader toolbar allowed any user to select and copy the full text of the document. Oops!

A couple of months ago, before this news story surfaced, I was typesetting a manuscript in which the author attacked an advertisement for a weight-loss remedy. To dramatize the fact that he was saying some rather nasty things about the advertised product, he chose to use black rectangles to block out the product’s name (rather than use a more traditional editorial device such as underscored spaces: _______). But, as with the TSA functionaries, the author had left the product name in the manuscript and applied a black highlight, rendering the name invisible to the eye but not to the cursor.

When I typeset the passage, I used a similar technique (applying a character style that rendered the word as a solid black rectangle). But before doing so, I replaced the product name with “<redacted>.” This text is not visible in the printed book. But should the author decide to produce an e-book later, in PDF or any other format, the product name will not be inadvertently revealed.

This is not rocket science. It’s just responsible tool use. Top-down management often presumes that anything a manager doesn’t already know isn’t important for anyone else to know either and that therefore training for subordinates is unnecessary. The TSA is disciplining five people who believed that.

Thursday, December 10, 2009

If one of those bottles should happen to fall...

According to Poynter Online, Nielsen is shutting down Kirkus Reviews and Editor & Publisher. Kirkus Reviews was one of the very few remaining pre-publication book review journals and was one of two or three relied on by librarians in planning their new book purchases.

The rationale for producing bound galleys or advance reading copies (ARCs) of books, with its built-in delay of four months before publishing the finished book, is looking weaker by the day.

Wednesday, December 02, 2009

Do you have the willies?

I’ll tell you a story. I’ll tell you no lies.
Grammatically, there isn’t a blessed thing wrong with using will as a verb auxiliary. If you look it up, you will find that I’m correct. If you enter a signed comment and satisfactorily respond to the Captcha challenge, your comment will appear. So don’t get me wrong here. I will not tell you that using will is grammatically wrong.

But in technical writing, particularly in American English (British English tech writing has different conventions), the best practice is to avoid the use of will unless you are talking about a future event. Enter your street address and city. The software looks up (not “will look up”) your zip code.

Why did this become a rule? Simple. Technical documents are written for a broad audience that may include a significant number of people for whom English is not the first language. Different languages have different arrays of tenses and different ways of indicating them. For a software user who is not a native speaker of English, will may always trigger the assumption that the writer is discussing a future event, even though that’s not always what the word means to a native speaker. The sentence then becomes ambiguous: The software looks up my zip code as soon as I tab over to the next field, the software will look up my zip code tonight, during a batch process, or the software will look up my zip code when the next version is released? I can’t answer that question with any confidence until I run a test case, and my boss told me not to run test cases because they will corrupt the database. So I’m confused; and if I’m confused, that means the technical writer let me down.

Where there’s a will, there’s a potential for confusion. If you are trying to communicate unambiguously in a context where you do not know the linguistic capabilities of your audience, don’t have the willies.

Tuesday, December 01, 2009

POP! at Yale Rep

Props to my much better half for her one-liner on the way home tonight: “Reminds me of the Shakespeare play.” Wait for it. “Much ado about nothing.”

Don’t take that as a dig at POP! though. Yale Rep has mounted the world premiere of a rollicking musical about Andy Warhol, and it is Warhol who extolled Nothing.

The strength of musical theater, as of the operetta it derives from, is rarely the plot. Oh, there have been exceptions, but POP! isn’t one of them, and if that’s going to spoil your fun, stay home and read a mystery. POP! is an As you know, Bob, that consists of character sketches—and I do mean character—of a handful of the Factory regulars back in 1968. In structure, it is reminiscent of Steve Martin’s Picasso at the Lapin Agile (maybe it should have been called Who Shot Andy Rabbit?).

The play unfolds—no, it exfoliates—in one long act (1:40). The sets and staging are at the same brilliant level we’ve come to expect from Yale Rep. Casting, acting, and singing were all superb. I especially appreciated the sound work, as I heard every lyric clearly, something I no longer expect but want to applaud when I get it.

The action—er, exposition—takes place on June 3, 1968. Bonus points and a discount blog subscription to the first commenter who names two other events, both fictional, memorialized in songs centered on June 3.