Posts in HowTo
Ken's Guide to Indie Publishing on Linux (Cover Design 3)

I'm now going to walk through the details of the cover design for my forthcoming book The Way Around. There may seem to be a lot of steps but, as with the interior, the time investment is small compared to writing the book itself! Each of my novels has taken about 500 hours to write and edit to completion. By comparison, the cover only took a few hours. Yet it’s the cover which sells the book!

The first time I created a cover, it took 4ish hours (I didn’t do the actual artwork, of course). Subsequent revisions have a gone a lot quicker. Though there are many words in these posts, the actual ideas are relatively simple.

Because my own process involved several “redos”, and that’s natural, I’ll include some of those additional steps in the narrative. This will help clarify how to fix mistakes (or accommodate changes), and show that such things are relatively painless.

One important thing with cover design is to do as much calculation by hand as possible. The less you have to aim a mouse to get things just right, the less you’ll want to fling yourself, the book, and the entire design profession off the top of a tall building.

So we’ll start with a simple but essential calculation: the aspect ratio of the image.

Step 1: Compute the correct aspect ratio

We have a template from Ingram. In theory, this tells us precisely what we need. In reality, we are given only a set of blue and pink regions and it is left to us to figure out the actual dimensions. Fortunately, this is not hard.

In Inkscape, the ruler tool will do the trick. Unfortunately, there is no simple aspect-ratio tool I’m aware of. But using the ruler at a big enough magnification (to allow precision) will give a pretty good estimate. I suggest setting the units to inches.

Why do we care about the aspect ratio (one number) and not the actual dimensions (two numbers)? It is very easy to scale images in Inkscape, but much more troublesome to crop them. What we want to start with is a very high-resolution image of the correct aspect ratio.

First let’s look at the Ingram Template a bit more closely, though. It comes in the form of a pdf representing a 15x12" sheet. On this sheet is an active region consisting of pink and blue rectangles. The pink is the part guaranteed to be printed, while the blue is bleed. It allows for variation in the print process. To produce the cover file they require, you must replace the active part of the template with your own cover image. Both pink and blue should be fully covered, but any active elements (title, isbn, etc) should sit only in the pink region. As a general rule of thumb, each overlaid pink region should look good by itself — as well as with a little extra added around the edges.

In my case, the active region consists of a 0.25" blue border, two pink pages (each 5x8, the size of my book), and a spine which is 0.259 wide with two bleeds, each 0.125". Note that the spine measurement includes some of the blue.

Horizontally we have

0.25in blue
4.75in pink
0.125in blue
0.259in blue/pink/blue (a little blue, pink, a little blue)
0.125in blue
4.75in pink
0.25in blue

These add up to 10.509 in.

Vertically, we have

0.25in blue
7.75in pink
0.25in blue

These add up to 8.25 in.

To compute our aspect ratio, we divide these and get 1.27381. We don’t need this to achieve this exactly, of course. But if we miss the target we’ll have to expand the image accordingly, which will lose a little from one edge or another. Best to get as close to the aspect ratio up front in a way we like and then lose only a pixel or two when we tweak it.

Step 2: Crop the illustration to the desired aspect ratio

We next need to crop the raw illustration to our aspect ratio. In my case, cropping would also remove any non-illustration cruft from the image (fade-off near the edge of the page and the artist information at the bottom).

As it later turned out, the nature of the illustration required an additional design choice. Certain imagery (a big tree in particular) would have wrapped onto the spine in a displeasing manner as things stood, so I decided to further crop the image while maintaining the aspect ratio. I’ll discuss that later on, but for now we’ll crop as little as possible.

There are two ways to do this, and which approach you take is a personal preference. I’ve used both.

Method 1: GIMP. The photoshop-alternative GIMP has a nifty feature which lets you create a constant-aspect ratio box and then place it over the image and crop to it. Better yet, GIMP allows you to manually enter the aspect ratio. When saving, it’s best to write a png file with no compression. Mine came to 150 MB.

Method 2: Imagemagick. You can use a command-line approach and try cropping in different ways (directly enforcing the aspect ratio by hand), and use eog or some other image viewer to see what looks right. The back and forth is less painful than it sounds, and probably would take no more than 5 minutes.

This is a good point at which to mention some handy Imagemagick commands.

“identify myfile” will provide useful info about the pixel dimensions of an image.

“convert oldfile [options] newfile” is the command to do most manipulations — file format conversions, cropping, etc. Here’s a cropping example, with an explanation of the relevant options:

“convert oldfile.jpg -gravity mychoice -crop 80%x80%+0+0 +repage -quality 80 newfile.jpg

-crop tells it to crop to a given size with a certain displacement from the reference point. If you’re cropping against a corner, the displacement should be +0+0 otherwise the suitable +x+y in pixels. The 80%x80% says to crop width and height to 80% each. Exact pixels like -crop 7958x6247+0+0 could be used too.

-gravity tells it what the reference point is. “mychoice” can be any of the following: SouthWest removes from top and right, SouthEast removes from top and left, NorthWest removes from bottom and right, and NorthEast removes from bottom and left.

-quality tells it the compression level to use when writing to a compressed format (jpg, png, etc). I recommend using 100 for all our purposes. We’ll use lower quality down the road when meeting file-size constraints for certain purposes. But for printing, we need the best quality possible.

+repage This is a technical option. When cropping occurs, the cropped image can be thought of as its own thing or as sitting on a canvas that was the original size. Each approach can be useful in some contexts. +repage tells it to treat the new image as its own thing (i.e. set the canvas to equal the cropped dimensions). This almost invariably is what we want for our purposes.

It’s also useful to know how to resize an image, even though we aren’t doing that here. Resizing is actually a challenging task in general because tradeoffs need to be made in terms of how sampling occurs. I find the defaults in Imagemagick serve well for simple purposes. To resize (scale instead of crop):

“convert oldfile.jpg -resize spec -quality 100 outfile.jpg”

Here, spec tells it how to resize. It can do so to an arbitrary widthxheight (pixels or percent). But it also can do so to a given width (ex. -resize 100) or height (ex. -resize x100) keeping the aspect ratio.

Resizing is another handy way to reduce file sizes. While resampling to higher resolutions can serve some purposes, we’ll have no need of it in general. Our original image is very high resolution and all our resizing will be down.

Step 3: Generate Logo

At this point we’ll make a minor digression, because we need to produce a mini logo for the spine. If for some reason you’re not using your own imprint, or if you already have a suitable image for it (or its just a simple text logo), then this step is unnecessary. Also, don’t worry if you don’t understand the details. We’ll discuss the use of LaTeX when it comes to the interior of the book. Feel free to return to it at that point.

Inkscape’s own tools suffice when it comes to most text elements, but it happens that my own imprint requires a little bit of finesse. The formal name of the press is “Epsilon Books” but the logo begins with a particular type of curly Greek epsilon rather than an E.

The following LaTex code did the trick:

\vglue -1.84in
\hglue -1.4in
{\fontsize{60pt}{0}\selectfont\textbf{\textepsilon}}{\fontsize{40pt}{0}\selectfont \hglue -1pt \textbf{psilon}}

Most of this is cruft necessary to declare the type of document. Worry not, when it comes to the interior the cruft to content ratio will be much lower. Think of it like the overhead necessary to write a C program. It seems like a lot of effort for “Hello World,” but is relatively insignificant for any real program. In any event, it took a few minutes of tweaking to get things right and I was done.

To compile it, I ran "pdflatex mylogo.tex", which produced the following pdf:

Ken’s Guide to Free Indie Publishing on Linux. Imagemagick and LaTeX example.

Step 4: Adjust Alpha Channel

I’ve separated out this step, even though it’s really a simple adjustment to the logo we generated. Even if you skipped that section, you may find the information in this section worth knowing. While the logo and its vagaries are specific to me, this is a good place to discuss the alpha channel.

The logo above may look good, but we must be careful. The background is transparent. As it turns out, that is fine for our purposes, but I should take the opportunity to explain a bit about what it means and its implications. When displayed in some programs it will look no different than a white background. On others it may mask the foreground image — appearing as a solid block of black. And on yet others the background may appear greyed out. It all depends what canvas a program decides to display it against.

When I was a kid, there were 3 color channels. The color of any pixel could be determined by those three numbers. Actually it started as 2 bits for CGA, then 4 bits for EGA, then 8 bits for VGA. Only later did it resolve into the 3 distinct RGB channels (24 bits total) once graphic cards could drive that many colors. But the idea is the same: each pixel’s “color” solely was determined by some representation of its physical place on the spectrum. This was fine for many purposes.

However, photo manipulation programs and other design tools evolved the notion of layering as a convenient means of mimicking the real design process. To be useful, layers needed the ability to blend into one another. While it’s possible to identify the background color and map or merge pixels accordingly, this can lead to other problems (misassignment of colors, misidentification of the background color, etc). In fact, many images have no clear notion of “background” vs “foreground” colors. So an “alpha” channel was added, an additional 8 bits. It represents absence of information, transparency, or whatever else we want to call it. Intuitively, it is a 4th number which tells us how transparent the image is. No doubt my little history blurb is wildly inaccurate, but the basic idea of the alpha channel is important.

Not all formats can accommodate it, and not all programs can recognize it. The main problem is knowing it is there, and the effect it can have. Sometimes we want it, sometimes we don’t. From a practical standpoint, if a picture overlays in a weird way, then there’s a good chance either the alpha channel is present and you don’t want it or it’s absent and you do want it. Imagemagick’s “identify” tool can help you make that determination.

In the case of my logo, the alpha channel is there and set to full transparency. We want this, since the logo will be overlaid on the image. But we don’t want the foreground color to be black. The cover image is dark and we need a white logo. As it turns out we’ll have to take further measures to ensure spine text visibility as well, but we’ll get to that later. For now, we just want to make the foreground white while retaining the alpha channel.

Looking ahead a little, it turns out that Inkscape has a slightly easier time importing SVGs than PDFs. There’s no good reason for this, and it’s just one of the idiosyncracies of the program (every program has them). So we’ll convert to SVG format.

We accomplish both steps with one command:

"convert mylogo.pdf -negate mylogo.svg”

Now that we’ve gathered all the necessary pieces, we can begin work assembling them into a cover. Next week, we’ll begin work in Inkscape. If you haven’t yet, it may be worth playing around with it a little and familiarizing yourself with how its menus, palettes, and so on.

Ken's Guide: Indie Publishing on Linux (Cover Design I)
How to create a book cover on linux using open source tools. (Image

Ordinarily, cover design is one of the last steps in book production, but because I happen to be at that exact stage with my second book of short works, The Way Around, I figure it is better to describe the details while they're fresh in my head. Moreover, there is at least one aspect of cover design which should be initiated early --- perhaps even before the book is complete. The time-line depends heavily on how you intend to approach the cover, and we discuss it in more detail below.

As with out discussion of the interior, we assume there will be paperback, hardcover, and Kindle editions of the book. The print editions will be through Ingram-Spark for our purposes. Similar considerations apply when printing via Createspace, but the constraints may vary.

Illustration vs Design

There are two key conceptual components to the cover: illustration and design. In practice, the two may be fully integrated or completely distinct. In simple terms, "illustration" is the imagery on the cover and "design" is the placement of various elements. The illustration may be one large image, several images, a photo, or no image at all --- perhaps just some clever line-work. There is no limit to the clever variation which is possible, though care should be taken not to lose sight of the ultimate goal: selling books.

A note on etiquette: Anyone other than the author involved in the creative aspects of the cover should be acknowledged somewhere. I do this on the copyright page with lines like:

"Cover Illustration by so-and-so"

"Cover Design by so-and-so"

To distinguish the cover itself from the specific elements on it, we'll refer to a "cover image" as any full cover file, such as you'd provide to Amazon or Ingram or other services. The actual imagery will either be referred to as such or as “illustrations.”

Our Goal

Contrary to what one may imagine, a single cover image rarely suffices. Several versions are necessary for different purposes. Let's start by listing the cover images you may need. The exact set will depend on which formats you intend to publish and the details of your marketing For our purposes, we'll assume a paperback, a hardcover with dustjacket, and a kindle edition. For these, we'll need the following files:

1. Paperback cover: A single image file containing the back cover, spine, and front cover unfolded onto one large page. This will be a very high resolution PDF built from an Ingram-provided template.

2. Hardcover dustjacket: Another single image file containing the inside right flap, the back cover, the spine, the front cover, and the inside left flap unfolded into one large page (imagine the dustjacket removed and laid flat). This too is a very high resolution PDF built from an Ingram-provided template.

3. Front cover image: This is necessary for a variety of purposes. You'll need jpg, png, and pdf versions at various resolutions and perhaps aspect ratios. Here are a few examples of uses:

Kindle edition front cover

Amazon listing of book

Ingram listing of book

Kirkus review


Goodreads listing

Amazon "look-inside"

Your own blog/website or anywhere you want to show it

Amazon recommends a 1.6x aspect ratio and 4500 x 2813 resolution. However, the choice is optional and other resolutions are possible. One thing to bear in mind is that various aspect rations may be necessary to generate the thumbnail-sized images which arise in various places. Also, Amazon's recommendation isn't written in stone even for Kindle editions.

It is easy to resize (via high-quality resampling, if necessary), crop, or place an image on a background of a different size using ImageMagick.

4. Back cover image: For some purposes, a separate back cover image is needed. For example, the Kindle edition optionally includes one, as does Amazon Look-Inside. Note that you may need 2 versions. Generally, the front cover will be just like a cut-out from the paperback cover image. However, an ISBN appears on the rear of the paperback cover --- and this is specific to that format. For the Kindle edition, you'll want an rear-cover image with either no ISBN or the appropriate ISBN for the ebook. For the look-inside version, I recommend no ISBN.

Some timeline considerations

This is a good place to make a small digression about time-line. Although the cover may seem like the last stage in book design, having a usable version is critical for many pre-publication tasks. As I learned through bitter experience, lack of planning (or, in my case, bad luck involving the illustrator) can delay the project and throw quite a large wrench in the marketing plan. For most pre-publication purposes, a workable front cover will suffice, however.

To complete the cover, you will need several key items:

1. The ISBN. This is easy enough. If you (or your imprint) own a block — as you should — you can assign one at any time. Although Ingram demands an ISBN to provide a cover template, a fake one will do fine. When you eventually assign an ISBN, just obtain a new template from Ingram and copy the relevant ISBN object. ISBNs are easy and quick to purchase (though annoyingly pricey), so this can be done at any time. That said, having an ISBN on hand is very useful for many other purposes --- and I recommend assigning one early in the game.

2. Title. It's surprising how often this can change up until the last minute. You can do most of the work without it --- but be prepared for some serious adaptation if it becomes a lot longer or shorter! Also, the title design can be tweaked until the last minute.

3. Author Name. You probably know your own name, but you need to choose a presentation. First Last, First M Last, First Middle Last, F.M. Last, a single super-hip letter, the being formerly known as …

4. Reviews/Bio. If you want a review/bio on the cover, you’ll need it. A placeholder can be setup, but without the actual text it will be difficult to get things just right. Personally, I don't recommend a cover-review or bio, for reasons I explain below. Be aware that reviews take time. Services like Kirkus require a couple of months, and individual bloggers/authors may take a lot longer.

5. Trim size. You need to pick the physical dimensions of the book. Is it 5x8, 6x9, etc? While it's relatively easy to adapt most interiors to differing dimensions, cover illustrations are a different matter --- especially if they have been created with one aspect-ratio in mind.

6. Page count. In my experience, this is the biggest nuisance. It's very common for the page count to change late in the game. This can happen for many reasons --- editing, the edition of back-matter, etc. Small changes like the addition or removal of a couple of pages are easier to manage but still may require some rejiggering. Large changes may require substantial reworking of the cover. Why is Page Count relevant? After all, only the trim size should matter for the cover illustrations, right? The problem is the spine width. Even if there isn't one big illustration which wraps around the cover, the placement of various elements needs to be adjusted. At the very least, a new template must be downloaded from Ingram --- and the elements adjusted onto it.

One key piece of advice: if you're hiring an illustrator and/or designer, do so very early in the game. They can require a couple of months (or more), and this can hold up the cover, which then cascades into a slew of other delays and problems. The pre-publication dance is a delicate one, and it's best to plan ahead if at all possible. Pick an aspect ratio, lock down a page-count as best possible, and get the imagery done. You (or the illustrator) can tweak it later.

For our purposes, I will assume you are doing what I did for my first 2 books: hiring an artist to produce physical pieces of art (along with scans of them), and then doing the cover design separately. There are advantages and disadvantages to this approach. For The Man Who Stands in Line, I hired a separate designer to create a cover design using the artwork. With The Way Around, I'm doing the cover design myself, using the artwork I commissioned. A more common approach is to have a single illustrator/designer do both digitally.

Some General Suggestions

It is important to understand that POD (print-on-demand) is not exact. Neither is offset printing or any other technology — but in the case of POD the variations occur at the level of individual orders, while with traditional publishing technologies the variations are by batch. Variations are a known and accepted part of the industry, and the very language of typesetting (trims and bleeds) incorporates it. The fact is that books are printed from large sheets which must be cut. Both the printing and cutting steps may introduce slight variations. It is best to be prepared for these and plan the design with them in mind to avoid disappointment and frustration. This isn't to say you can't have a beautiful cover. You just need to work within the practical constraints of the system.

The following are some things to keep in mind. I prefer large illustrations which include both covers and the spine, but the same considerations apply if you have separate front and/or back cover illustrations.

1. There is variation in the centering of the front cover. This generally isn't noticeable unless the cover image or text is framed in some manner (even a clear boundary will do) near the edge of the cover. Avoid frames or other elements whose exact placement is essential for the cover to look good. Big wrap-around illustrations can avoid this, as long as there is no critical element which has to align against one of the cover edges. In general, a lack of symmetry is preferable to a slight misalignment. Small variations tell us that a mistake was made, large ones are imputed to design. To avoid compromising the aesthetics it is best to place any border elements away from edges — use a smaller bounding box or decorative element — or avoid them altogether.

2. The most noticeable variation, in my experience, is with spine text. Createspace doesn't even allow spine text for books 130 pages or shorter. Ingram requires only 48 pages. But the concerns are the same. Vertical variations in placement will be less noticeable than horizontal ones — as long as nothing is too close to the top or bottom. Left-right placement can be an issue, though --- so make the spine text small, with good margins on both sides. Also, make sure it isn't framed in any way. Otherwise the frame could look off-center or push onto the cover. If you follow these tips, spine text should come out quite well.

3. If a large image is used (wrapping around both covers and spine), it may be necessary to fade it along the spine to make the spine-text visible. This has been the case with both of my books so far. Spine text, in my opinion is very important. It should either be a very bright or very dark color (I use black or white) depending on the underlying image --- but it all should one color. It may be tempting to simply block out the image on the spine and simply have text — but that won’t work well. The blackened (or whitened) block constitutes a rectangle and may be noticeably displaced, sliding onto or off the spine. My approach is to create a layer with such a rectangle, and make it partly transparent. Then I blur it into the surrounding image to remove any noticeable edge. This sounds complicated, but actually is quite straightforward.

The Printer

As will be discussed elsewhere, there currently are two major options for POD printing: Createspace (Amazon), and Ingram-Spark (Lightning Source). I much prefer Ingram-Spark for several reasons. In particular, I've found their quality to be better than Createspace’s and they also are more flexible in terms of printing spine text on thinner books. I've printed one book of my own and have been involved in the printing of two others with Ingram --- and they've all come out beautiful. This said, printers change and quality can vary --- so it's best to do some research. There is no meaningful disadvantage to selling an Ingram book through Amazon.

Ingram-Spark is the retail facing end of Lighting Source, a major printer for lots of traditional presses. This has upsides. For example, by printing through Ingram your book automatically is available through to most physical bookstores via their distribution network. However, one big downside to dealing with Ingram is that Lightning Source is a big clunky company used to dealing with dedicated publishing personnel and large orders via invoice, etc. They produce a great product but you'll have to deal with a very primitive process. On the other hand, Amazon's Kindle-production process is even more frustrating despite being more modern.

Until recently, Ingram required PDF/X files. These are PDF files with certain guarantees built in --- so most PDFs wouldn't qualify. This wasn't a major issue (Ghostscript could generate them easily enough), but something to be cognizant of. Now they seem to accept regular PDFs. There are 2 key things they need in their PDFs, though:

  1. Embedded fonts. This can be checked with the command line program pdffonts, and is more of a concern for the interior than the cover. This said, it must be true for both.

  2. CMYK vs RGB. If the interior is color then this applies to that as well as the cover. CMYK is the color scheme used for printing, while RGB is that for on-screen viewing. Each is based on the native process involved in the respective technology. Many PDFs produced default to RGB. We will need to make sure that all print-ready PDFs are CMYK. It is easy to do, but something we must keep in mind.

Expect the back-and-forth with Ingram to take at least a couple of weeks and cost a few bucks. In my experience, they haven't been jerks about the "file change" fees when there are serious problems, but you still need to buy copies of your book to inspect them. There's no getting around this. You'll buy these at cost, but the shipping can be fractionally large for small orders.

Basically, you'll submit the interior and cover files and they'll tell you (after a day or two) whether they've been accepted by their automated system. Then you'll be able to inspect galleys online --- but that won't tell you anything about what the book actually will look like (at least color-wise). The only way to find that out is to order a copy. Order a couple, make any changes, then repeat the process, etc. If you screwed up or decided to change some things on your own, you may have to pay the $25 file-change fee. If it was their fault (some awful misalignment, etc) they won't charge you. Be firm and be insistent. Often, their people will claim they didn't screw up when they did. If you’ve followed my advice above, once everything looks good, future printing should be (more or less) spot on. Most issues arise up-front with how they process the files, map colors, etc. What you're dealing with is exactly what every publisher has had to deal with for every book. Be polite, but be firm (if you're in the right).

Ingram offers a few useful tools and guides.

1. Ingram Cover Template: If you don't have an ISBN, make one up in order to get a template of the right dimensions until the book is printed. It's just used for barcode generation for the template, so using one from an existing book will work too. Of course, it's best to have your own ISBN ready — and certainly don't forget to replace the placeholder with a real one when the time comes!

2. Ingram Spine Width Estimator: This is a helpful tool, but I suggest using the cover template instead.

3. File Creation Guide: This describes their guidelines for both the interior and cover. The cover part won't be necessary since we're using their template --- but it can be enlightening to read it.

4. They also have a helpful checklist with some handy tips.

The Tools

Now let's examine the tools we will use for the cover design. These are (largely) independent of those used for interior layout. Not all are essential, but I'll include the ones I find handy.

Cover design on Linux poses a unique challenge. Emacs and Vim (and others) long ago solved the problem of efficiently writing on Linux. TeX (and LaTeX) long ago solved the typesetting problem. But illustration and cover design are a little less polished on Linux. Perfectly serviceable, but not quite as polished as some commercial tools. This isn't surprising. If there's anywhere a windowing OS and mouse-based approach can shine it's in design and illustration. Fortunately, we need only wade into those waters to create a gorgeous cover. For that, the tools at hand are more than enough.

For the most part, illustration and design typically are done by trendy people in cafes working on Macs and using very expensive Adobe or Apple software. There are many reasons not to do that, besides expense. Some of these tools (cough Adobe cough) are more invasive than malware and can destabilize even a solid Linux system. The bad news is that there are no free Linux tools fully equivalent to these. The good news is that, as far as cover design goes, it doesn't matter. There are perfectly suitable tools which can solve our particular problem quite well.

I suggest installing the following:

1. imagemagick: Great for command-line image conversions, cropping, negation, etc. The two utilities we will make the most use of are "convert" and "identify".

2. eog: A good lightweight image viewer. Any such viewer will do.

3. gimp: This is the freeware alternative to Adobe Photoshop. I won't get into whether it is comparable, but for our purposes it is more than sufficient. We'll just use it to crop large images. Imagemagick can crop just as effectively, but for this one step in our process visual feedback will prove useful.

4. inkscape: This loosely can be described as the open-source answer to Adobe Illustrator. It's a vector drawing program, but also has layout capabilities, and is more than capable of what we need to accomplish.

5. scribus: Although I'm not currently using this for cover design, it too is capable of serving our purpose. Some may find it preferable. Scribus loosely can be described as the free alternative to Indesign.

6. pdffonts: I mentioned this above as a means to determine whether fonts are embedded. It is part of the poppler-tools package.

I should point out that although gimp, inkscape, and scribus are very powerful in their own right, they are not necessarily compatible with their Adobe counterparts. In particular, there is no support for Indesign files (this article hints at a workaround, though: This isn't an issue for us, because Ingram offers its templates as PDFs as well. However, if an illustrator/designer is employed it may be important to make sure they provide files in some compatible format to allow for future tweaking on your end.

In truth, any of the three — gimp, inkscape, or scribus — can fully serve for our cover design. I currently use inkscape, but all three easily can accomplish the rudimentary tasks we require. Which to use is a matter of personal taste.

Next Week

So far we’ve had lots of blather about tools and preferences and guidelines without really getting our hands dirty. That’s about to change. I suggest that this week you install the recommended programs and play around a little with them. Next week we will begin working on an actual cover.

Ken's Guide: Indie Publishing on Linux (2. Three Key Preferences)
how to self-publish on linux, part 2 preferences

There are three key preferences I express in this and my other guides, and it is worth explaining them. They all inform my choices and approaches, though some play a larger role than others.

Why Linux?

Linux is a very stable operating system, it is powerful, and it gets out of your way. My goal isn't to start an OS flame-war. I've used all 3 at various points, and will be the first to admit that Linux has its drawbacks. But in my experience both Windows and OSX are clunky, unstable, and designed around certain tradeoffs which work to my disadvantage. These tradeoffs favor certain uses and workflows at the expense of others, and unfortunately writing is one of those others. Both OS'es seem to be moving toward a heavy emphasis on mobile device use, content consumption, and web-design applications.

However, I speak of the general approach taken by the OS'es. Any of the three can be made to do anything --- it's just a question of ease. If you're wed to Windows or OSX, then that's not a problem. The remainder of my guide will still be useful, but you may find some adaptation necessary. In addition to full Windows/OSX ports of some packages I mention, both Windows and OSX have some Unix support built in. OSX actually is layered on a flavor of Unix and offers a proper command-line. Homebrew or its ilk may be used to install packages, and much of what I describe directly carries over. Limited Unix tools are available on older versions of Windows via cygwin. I'm told that the newest version of Windows offers a full Unix carriage.

If you want to use (or try) Linux but simply don't wish to purchase a new computer, that's no problem either. Linux easily may be installed in a VM using free software like Virtualbox (available on both Windows and OSX). Modern hardware has direct virtualization support and the installed instance will run at near-native speed.

Why a text-based environment (i.e. the command-line)?

I use an almost exclusively command-line environment. There are several text-based windows managers on Linux, all quite good. If you're curious, I happen to use i3. There are important reasons why I feel a command-line environment is preferable to a graphic window-manager. But first, I should clarify something. A text-based window-manager does not preclude the use of graphical programs. It just allows me to avoid the use of a mouse under other circumstances. I still can pull up Gimp, Inkscape, or any other fully-graphical program and mouse my way around it like anyone else. But when I'm not using a graphics program, I'm not forced to use a mouse to switch windows, move around, and so on. And yes, I have an aversion to mice. Not the cute furry kind that stop being cute and furry when they decide to pass away in the attic and stink up the whole house for a week. I think mice are one of the worst things to happen to computers. They started as a great tool. But like anything new and flashy, they quickly evolved from "had-to-have" to HAD to have. But this was part of a broader trend.

My experience has been that as computers grew more powerful and snazzier, basic software grew less functional. In the late 80s to mid 90s, I used a variety of excellent programs. Wordperfect was a solid word processor, Irfanview was a great photo-library manager, and treepad was an excellent PIM --- to name a few Windows examples. This isn't simple nostalgia. I've used countless products since, some quite good in other ways. However, the basic usability has declined. Programs have gotten bigger, offering lots of features that I don't use, yet have regressed when it comes to the basics. I won't go into the causes of this --- there are several, some organic, others related to market dynamics and programming fads. But the gist is that power has gone up and core functionality has declined. Or, more precisely, core functionality of popular commercial software has done so.

As mentioned, one of my biggest problems is the mouse. The trouble with a mouse is that it forces an interruption of mental focus --- at least when it comes to tasks like writing. When invented, the mouse was a godsend (though I personally prefer trackballs, certain trackpads, and mini-joysticks). I'm not a luddite in this regard. I even have a Space-nav 6-axis mouse. It's amazing and nifty and perfect for one or two applications I almost never use. But if I were a CAD designer or graphic artist it probably would be indispensable. The same is true of the mouse. There are applications in design and elsewhere for which a mouse is a major blessing. But I find that it generally slows down my workflow more than anything else. Nowhere is this more evident than in word-processing.

Early on, the mouse allowed the coupling of word-processing and desktop-publication software. This was amazingly cool and very counterproductive. There's a reason that content and form are kept separate in most writing workflows. Imagine a writer in the old days who insisted on manually typesetting his work every so often — just to see how it would come out. He’d probably produce a single book in his lifetime. And it would be on the benefits of typesetting while writing. There are indeed benefits to having some sense of what a piece will look like, particularly with visual forms such as verse. And it certainly can be fun and motivating for an amateur writer to do so. However, in my experience serious thought and writing is undermined by the visual distraction associated with the constant reflowing of text or other visual aids in modern word processors. But it is difficult to avoid this in modern graphical environments. The problem is that content and form have become inseparable --- literally --- in most applications. And the emphasis on web-publication has made this much much worse.

The end result is that a mouse now is required even for the simplest tasks, and we're constantly distracted from our purpose. Windowing OS'es also tend to require a lot of mouse-related intervention of their own: dialogs, popups, and so on. Each requires a change of mental focus.

It is my experience --- and this is highly subjective --- that this is not the case when performing comparable tasks in something like Emacs. I personally find that between Emacs and various unix utilities I can accomplish most tasks far faster via keyboard than I ever could with comparable mouse-based applications. Nor do I mean to proselytize about Emacs. Vim or any other text-based tool offers the same benefit.

One other issue with a mouse vs keyboard is precision. For layout purposes, placement with a mouse is inexact (even with snap-to grids), and unstable. In my opinion, it is much better to have a written specification in terms of numbers --- which then can be adjusted to achieve the desired goal. But that has more to do with the software’s internal model, its exposure to the user, and our ability to modify things programmatically.

Why text files?

Another major choice involves text-vs-proprietary formats for storage. There is nothing magical about a text file --- its just a collection of bits like any other file. Text files do have a few advantages, however. They generally are easily-readable by humans and there are many free and well-established utilities to manipulate them. With text files, one is less tied to a specific application. Conversion is easy, either directly or using a script. Basically, text has been around a long time, will be here for a long time, and is well-supported.

Of course, I'm being a little glib here. There are many text-based formats, some as abstruse as any binary format. Moreover, I’ve conflated two separate dichotomies: text vs binary and open vs proprietary are two separate issues. But for our purposes, I can lump them together here. It is important to keep the distinction in mind, however. For example, XML, JSON, and other formats are manageable and open (unless there is a closed schema) but lose many of the benefits of plain text. Note that I'm being purposely vague about what I mean by "text" here.

The basic idea I'm trying to convey is that if our book-related information is stored in some sort of human-readable text format, there are lots of advantages. Some apply to all text-files vs binary, some to human-readable vs non-human-readable, and some to open vs proprietary. But human-readable-text offers the greatest benefits.

Consider Latex as an example. LaTeX (or it's parent TeX) is a text-based formatting language predominantly use for scientific and technical documents. However, it also happens to be fantastic for non-scientific typesetting. Unlike XML, it is human-readable. It is incredibly flexible and can produce books on par with any professional product. A LaTeX file will have some detailed layout information up front, but for non-scientific writing the body of the document typically has little markup.

An even simpler --- if less powerful --- alternative is markdown, and in fact I use this for my novels. It is far less flexible than LaTeX but also can be a bit cleaner to look at. Fortunately, there are tools (such as pandoc) which allow easy conversion --- so one can have most of the power of Latex along with the simplicity of markdown. I'll delve into this in another guide. For now, suffice to say that LaTeX and markdown both are human-readable and text-based. I can compile LaTeX into a print-ready pdf file which will display and print the same on any system.

Let us list the major advantages of human-readable open-format text files over proprietary binary ones. Many of these apply to human-readable text over HTML, XML, JSON, etc, as well.

1. Human readability. You can see what is being done and how. With something like Word, a minor change can cause all sorts of reformatting, and changes may not even be apparent. "Stuff happens," and you have to hope you can see it. An undo stack helps a little, but this is application-dependent and usually cannot be inspected or edited in a meaningful way. With a text file, you can make changes manually and force things to be just the way you want. You don't need to navigate all sorts of hierarchical menus to find something you hope changes the right setting or value.

2. Size and compressibility. Not as much an issue with the cheap availability of disk space these days, but still an indication of maintainability and complexity. Text files tend to be small and highly compressible.

3. Version control. Several very powerful and well-established VC systems exist. These primarily are designed to deal with text-files. Most can manage binary files too, but less efficiently. There is a clear semantic notion of diff (unix for difference) between text files. With proprietary binary formats, one must rely on the application to supply semantics to the VC system if there is to be any hope of meaningfully diff'ing versions. Since this almost never happens, one is forced to use each application’s own home-grown, opaque VC system. The same problem exists for non-proprietary binary files in general VC systems, of course, but users (in theory, at least) can create tools to do so. Proprietary formats admit no such accommodation.

4. Durability. Proprietary formats require continuing access to the program which created them. And not just the application in general, but often the specific version and accompanying OS version on which they existed. Modern subscription models make the situation worse. Users must pay for ongoing access to their own files! Exporting to some other format (if possible), often requires possession of a working copy of the original program. You may not even be able to tell what the file *is* until you open it in that program. With text-based files (or any standard format), you always can extract the info via a script. And you most certainly can tell what the file is about.

5. Interoperability. Text files are universal (aside from a few easily-dealt-with quirks like the use of carriage-returns). Binary files may not work on other OS's. Issues like word-boundaries, endianness, and meta-data can make a file incompatible (and perhaps even inaccessible) on another system. While the program may not exist to use the text file on another OS, you at least can inspect it, convert it, and extract some info. There is little danger that plain text will cease to be supported in the foreseeable future.

6. Editability. Text files easily can be edited. Binary ones can too, but the process is a lot more painful and less intuitive, and typically requires access to information that is not readily available. Although human-readability doesn't mean you meaningfully can edit a file without understanding the details of its use by the program, it *is* much easier to make changes when you do --- or to deduce which changes need to be made.

7. Search. Text files easily can be searched for human-readable phrases. If nothing else, this allows the detection of *which* files possess certain text, even if one doesn't know all the details of the file's format.

In summary, I recommend a text-based environment for human efficiency as a writer, and text-based formats for the powerful version-control and tools they admit. I recommend Linux because it allows all of this for free in a very stable package.

If you strongly disagree with any of these approaches, that doesn't mean this guide will be of no use to you. I recommend you read it anyway and try to adapt the relevant sections as best suits you. If nothing else, you may save some money by avoiding commercial software.

Next week, we’ll dive into the details of book production and get started with our cover!

Ken's Guide: Indie Publishing on Linux (1. Introduction)
Ken’s guide to producing a professional-quality self-published physical book using free software on Linux.  (Picture from Metropolitan Museum of Art)

The Purpose of this Guide

This is a guide to producing a professional-quality self-published physical book using free software on Linux. I believe it fills an important hole in the available offerings. There are countless books, websites, and blogs devoted to writing, producing, and marketing books. These almost exclusively focus on ebooks and the use of a windows/mac environment. Physical books generally are an afterthought, and often are treated as little more than printed copies of the ebook. In a very real sense, the tail has come to wag the dog.

Commercial tools for typesetting, design, and layout exist on PCs and Macs, but those tools and operating systems have major drawbacks. Navigating the forest of how-to sites on self-publishing, it is easy to get the impression that Linux is ill-suited to writing and publication. This is far from the truth. I'll say it now:

1. There is no better writing environment than Linux.

2. Every single stage of the writing, querying, and self-publication processes may be accomplished with aplomb using free software on Linux. For those who prefer not to use Linux, most of this software is available on PCs and Macs as well --- with all the attendant advantages.

This guide is the first in an anticipated series based on my own experiences writing, querying, and self-publishing a variety of books. Future guides will explore a Linux-based writing work-flow as well as practical aspects of novel writing.

Unlike many how-to posts which provide only generic information, I will offer details from my own projects. It is my hope that this will encourage others to explore Linux as a platform for their creative work. Perhaps a few programmer-types may even be inspired to try their hand at writing. Though mysterious and daunting from the outside, writing has a lot in common with software design. In fact, programming methodologies can be of great help in that endeavor.

Who is this for?

There are two key emphases in this guide: (1) producing a high-quality physical book, and (2) doing so using well-established free software on Linux. It is my hope that these posts will be of great utility to those interested in both aspects, of some utility to those interested in only one, and of potential interest to those exploring options or simply curious or open to new things.

Producing a professional-quality product requires an investment of time and effort. There's nothing wrong with choosing not to, though in that case this guide probably won't be of much use to you. But if you're just unsure, it may give you a clearer sense of what's involved. Hopefully, this will persuade rather than deter you from pursuing such a project.

The guide probably will be of use even to those not using Linux, and I recommend it to everyone who cares about producing a beautiful book. This said, most of what I describe requires some facility with the unix command-line. This can be easily enough acquired by anyone conversant with the basics of computing.

General Outline

The Tentative Plan is something like this (though I may add or rearrange posts):

This introduction
My Three Major Preferences
Cover Design I — General Considerations
Interior Design I — Front and Rear Matter Arrangement
Cover Design II — Step by Step Guide (imagery)
Cover Design III — Step by Step Guide (cover elements)
Cover Design IV — Step by Step Guide (file production)
Cover Design V — Illustration and Illustrators
Interior Design II — Basics of LaTeX and Markdown
Interior Design III — Margins, Fonts, and Spacing
Interior Design IV — Headers, Footers, and Other Elements
Interior Design V — Front and Rear Matter Specifics
Interior Production for Printing
Interior Production for Qeurying
Interior Production for Other purposes