Posts tagged how to print a book on linux
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