My self-publishing process: Page breaks

I have continued work on preparing Seen Sean? for publication. The phase I’m in now, formatting the PDF for the print book, is fixing bad page breaks. I am about 50% done with this subtask.

I’m typesetting the text in 10-point Computer Modern (really a great workaday font that’s not Times) with generous baselines. The paper size, 5¼×8", While typical for a trade paperback, is a little tight on space and robs some flexibility from pagination. Widows and orphans (a single line of a multi-line paragraph at the bottom or top of a page, and no, I can never remember which is the orphan and which is the widow) are commonplace, especially where paragraphs are short, e.g., in dialog.

LaTeX gives me a way to deal with this: the \enlargethispage macro. This macro allows me to enlarge a page (surprise!) by a defined amount that is given as a parameter to the macro call. The only parameters I have used so far are \baselineskip (to enlarge) and −\baselineskip (to shrink).

What is the heuristic (rule of thumb) that tells me when to grow a page and when to shrink one? The rule, which has been sufficient so far, is this:

• If a single line from the beginning of a paragraph is left at the bottom of a page, shrink.
• Otherwise, if a single line from the end of a paragraph is left at the top of a page, grow.

Notice that shrinking the page by 1 line is preferred. Shrinking or growing the page this way does not affect the overall page layout in any other way. In particular, the page number stays in the same place, glued to the bottom of the page, centered.

How do I iterate this process? As I page through the PDF, I find a bad break; this happens on about ⅓–½ of pages. Looking at the bottom of page n and the top of page n+1, I decide whether to shrink or grow the page. I switch windows into MacVim (or vile, depending on my mood that day) and insert the needed macro. (The 2 versions were previously saved in separate paste registers.) Then in a terminal window, I reformat the entire book. Finally, I switch back to Preview to see the result and look for the next bad break.

This has to be iterated over every page break, because, for instance, if I shrink a page, that means a line is added at the top of the next page, which may turn a bad break good or a good break bad.

Each page break takes much less than 1 minute to correct. The formatting from LaTeX source to PDF (which is what you’re probably balking at) takes about 1 second for the entire 278-page book. The number of pages has not changed so far, since the rearranged splits are buffered at the ends of chapters.

Of course, this doesn’t affect the e-books at all.

Why go through all this? Respect for the reader. I realize that very few of my sales will be paper books, but that is not a reason to treat those readers shabbily. Requiring at least 2 lines of each paragraph be on the same page physically eases reading.

My self-publishing process: 2. The back-cover text

For the next episode of the adventure, we explore typesetting the text that goes on the back cover of the paperback. This text will also be the main text that appears on the sales web sites, i.e., Amazon, B&N, etc.

I constructed the cover in The Gimp. Gimp uses layers, masks and transparency to organize your project in a manner similar (I’m told) to Photoshop. The overall cover design was complete some time ago, though I made one slight adjustment in how the photograph is masked.

The back-cover text, however, I just finished writing a few days ago, so I felt it was time to get it incorporated.

Seriously geeky stuff ahead. You’ve been warned.

The cover is made up of more than a dozen different pieces, each in its own graphical layer: the radial gradient background; each part of the text in a slightly peculiar handwriting font; the photograph, masked to an oval shape so only the model’s eyes are showing, but blurred at the edges into the background. All this is laid out on a template CreateSpace provides. CreateSpace will add the bar code after I have submitted the artwork. (I’m using the wrong template right now; more on that below.)

I had choices for how the back cover would be typeset:

• I could pull the (almost) completed project into some Adobe something (likely Photoshop).
• I could type the text into a text box in The Gimp.
• I could properly typeset the text and drop in the typeset copy. This gives proper kerning, hyphenation (needed for short lines).

In the end, I chose the last option because it would get me there the fastest with the bestest result.

I put the text into a LaTeX article document and began experimenting with typesetting options: Font family, font size, text width. Eventually I settled on

• The cmss font (Computer Modern Sans Serif), the font in which the chapter headings will be set in the book’s interior; it is a TeX staple. I got this by putting a command \sffamily around each paragraph.
• Font size: 14-15 points. For this, I used the [12pt] article option, then put a \large command inside each parpagraph. (Note to whining purists: This was six short paragraphs — not enough in my mind to trouble about doing it the “right” way.)
• I set the text width to 25em (based on the 12pt document option) by experimenting with it and pasting it (as outlined below) into the cover file until it looked “about right” to me.

I typeset the copy by running it through pdflatex, which embeds scalable fonts in the PDF, then opened it in The Gimp. When importing a Postscript or PDF document, Gimp gives you a choice in the resolution of the import. Through experimentation I selected 300 DPI, the same as the resolution of the CreateSpace cover template.

Once the file was imported (in a separate graphics file), I cropped it to just the text I wanted, i.e., disposing of the excess margins, page number, etc. (See comments above about doing it the right way.)

But the PDF import assumes the ink color is black and the paper color is white and both are opaque. That would be great if the back cover (at least) were going to be solid white, but in this case it was a recipe for ugly. So I took the cropped graphic of the text and inverted the colors, i.e., white became black and vice versa, and the brightness of grayscales was inverted, e.g., 25% white became 75% white.

Back in the book cover file, I created a new layer and added a layer mask that would give me full transparency. I pasted the “text graphic” not into the visible layer, but into the layer mask. See, a layer mask in the Gimp uses black for the transparent part of the layer, white for the opaque part of the layer, and partial transparency is done with shades of gray. So with the background of the text being black in the layer mask only the lettering would show, and that in whatever color I painted the foreground of the layer.

I did it this way for two reasons: to overcome the PDF black/white problem noted above, and to experiment with the color of the text. My brilliant idea was to have the text set in a gradient with enough contrast to the cover background to make it easily readable. But as with so much in life, the proof is in the pudding (in this case readability), not in the recipe. In the end, the back cover has solid white text over the gradient background.

One final note: I’m using the wrong CreateSpace template at this time because I don’t know how many pages will be in the final paperback. The only difference will be in the spine width, so when I know the actual page count, and thus can obtain the correct template, I will just need to rearrange the cover parts slightly to get the layout correct.

My self-publising process: 1. Self-editing

For the next few days, I’m going to explain here the steps I’m going through to get Seen Sean? out the (virtual) door. If you’re not interested, please ignore.

Okay, I have a manuscript. It has been through writes and rewrites, storyboarding, proofreading by three different individuals, and two more editing passes by me. In this post, I’ll tell you why I self-edit, and I’ll give a brief description of the final editing passes.

Why do I self-edit? Just one reason: Cost. A professional editor would charge about 2000 USD to work over a 60,000-word manuscript. I haven’t got that much to spend (and Seen Sean? is longer than that anyway), so I self-edit.

After I got the results from my proofreaders (Thanks Becky, Cathy and Andrew!) I printed a full manuscript for myself (single-spaced, two column text, just short of 100 pages) and went through it with a red pen. I hoped that would be my final pass, but alas! there were way too many edits. I knew I would have to do it all again.

But before the final pass, I decided to correct something I saw as I read: I used dashes (em-dashes “—”, not hyphens “-”, not minus signs “−”, not en-dashes “–”) and ellipses (that funny little thing of the three dots, “…”, which my wife pronounces “dah-dah-dah”) a lot, especially in dialog. So I started a pass, in the original computer file this time, to check just those bits of punctuation. As I see it, the dash means an interrupted thought; the ellipsis indicates a drawn out or incomplete thought.

As I got close to the end of that check I realized this: I use dashes and ellipses way too much. So I took the only reasonable course: I went through the entire manuscript again asking whether there was a better way to punctuate each use, and in some cases whether there was a better, more natural way to word the dialog, or in a few cases, action. There was a better way about 90% of the time.

Because of the amount of red ink on the last paper edit, I decided one more read-through was needed. I knew the manuscript was getting close with the punctuation straightened out, but I knew the story needed a final check.

So I formatted the manuscript into a .mobi file and side-loaded it onto my Kindle (a Kindle Keyboard wifi, née Kindle 3). I read Seen Sean? the way I read other people’s books, looking for wording that makes me cringe. I found about 180 problems, plus one (!) misspelling and one or two incorrect names, and noted everything using the Kindle’s highlighting and note-taking feature. I corrected everything, and now the manuscript is ready for the next step.

Stay tuned.