Showing posts with label fonts. Show all posts
Showing posts with label fonts. Show all posts

Sunday, 9 October 2016

Adventure #2 in publishing: The printed book!

Ouch — this article is way overdue: when I sat down to finish it, I saw I'd half written it back in February. Sorry! (In hindsight, I suspect I subconsciously realised it was going to be a long article and require a fair effort to finish, so I kept putting it off. I've also been very busy with writing and everything related to that.)

This article is about preparing a print edition of your book — which is a little more work than preparing the ebook edition for a novel that's not illustrated. Although there are significant differences for a printed edition, there are more things in common; so if some of these details look a bit sketchy, hopefully it's because I've covered them in my article about preparing the ebook edition — the two pieces are companion articles.

Here's a link to my earlier article about preparing the electronic edition: Adventure #1 in publishing: Creating the ebook!

Because this post is so long, I thought I'd better break it up into sections, and provide a table of contents:

Here's a short list of the new things you'll need to do, or may choose to do, and what this rather lengthy article covers:

New ISBN, PDFs for print edition, adjusted layout, CIP (kind of), costing info, return policy, discount, copyright, page numbers, left vs right layout, font size, costing info, proof copy, dates.

The reason I go into the detail I do here, is to try to capture most of what I've learned; so it's helpful for me and my imperfect memory, and I hope it will be of use to others. This article is unusually long; so rather than considering it as something to read from start to finish, it may make more sense to treat it as something to refer to if you're looking for an answer to a specific question. I wrote it, and I found it tediously long to read! But I think it'll be handy in five months time when I produce the print version for Volume 3.

Key differences in print vs electronic

I'll try to note all the differences between the print and digital editions of a book. My dream is to have a single electronic version of my book(s), and an automated process for generating both an ebook edition and each print edition; but currently I have a separate file for each. I try to be rigorous in ensuring each has the same content. When I make improvements in one edition, I make them in each other addition, at the same time.

New ISBN

Assuming you've bought one or more ISBNs, you need to choose a fresh ISBN to associate with this edition of your book. I've discussed ISBNs before when I wrote about "Preparing to Hit the Publish Button", but it's useful I think to go over it again in the context of a print edition, and perhaps with some missing details filled-in, too. Each physically different edition requires its own unique ISBN. But if you make substantive changes (more than just corrections), you should really use a new ISBN to distinguish the new edition. Check your nation's guidelines on their expectations in this area.

If you buy a block of ISBNs it makes it easier for book cataloguing databases around the world to decide your books are related (they tend to assume publishers have runs of sequential ISBNs). It also hugely reduces the per-ISBN cost.

Since I'm in Australia and the ISBN assignments are managed here by Thorpe-Bowker (https://www.myidentifiers.com.au/) I log in and visit My Profile (https://www.myidentifiers.com.au/myaccount_myprofile). There, under the "My Account" drop-down I choose "Manage ISBNs".

Currently I have several ISBNs set aside for Wild Thing. I assigned the first one to the ebook edition, since I published that first. I've reserved other ISBNs for other editions (5"x8" pbk, 4.25"x7" pbk, large print, but I'm even considering a UK English spelling edition, and a dyslexic-friendly ebook, and even a hard-cover). Choosing to publish all those variants would probably be excessive, so perhaps reserving five ISBNs for Wild Thing is more than reasonable for now! I've been keeping track of what ISBN I assigned to each edition in an email to myself. I'm unsure whether it'd be more sensible to use a spreadsheet. Of course, Thorpe-Bowker keep track of what I've assigned; but they don't know what I'm planning, so I think it's sensible to keep track of it myself, too.

Do you have URLs?

If you mention a web site in your text (such as a link to your author web site), then in the print edition, remember to spell out the actual URL; though if it starts with "http://" you can safely omit that. If you used colour text for hyperlinks in your ebook, change the text style to use black text in the print edition (unless you've opted for some colour for the insides, rather than B&W).

Spine tips

The vast majority of books print the text of the spine running "down": that is, you tilt your head to the right to read the words left to right (in roman script, at least). Have a skim of some bookshelves if you need to check this.

Also, if you are writing a series of books, give some thought to where the volume number should appear (readers really appreciate being easily able to sequentially order the books, so do include a number), and the title and author. These should line up nicely when shelved, so your books are pleasing to look at.

Typeface and font size

In other words, legibility and ease of reading. Unlike the ebook, your decision here may as well be carved in granite, since your readers certainly can't increase the font size if they have trouble. It's not hard to pick a typeface that suits the style of the book and is easily readable, but do put careful thought into the choice for the print edition in particular.

I've heard people claim that a sans-serif font (like Helvetica or Arial) is just as readable for long blocks of text as the serif fonts normally used for this (Time Roman, Garamond, etc.), and that there is no scientific evidence one way or the other.

I beg to differ. That flies in the face of reason (since the tiny details provided by the serifs are not there for decoration, they're subtle clues carefully created by expert type designers to help our marvellous pattern-recognising brains identify letters in an instant); it's also contrary to my personal experience; and more tellingly, Carnegie Mellon University researched this topic more than thirty years ago and published several papers. Their conclusion? Serif text was preferable to sans-serif for long pieces of text. I know this because my wife, a PhD in English and a professional technical writer of excellent skill, paid for copies of the research when the question came up, early in her career.

Your choice of typeface will affect how much space your text requires, and thus how many pages and therefore also the cost. And if you want a special font that's not provided as part of your computer system, beware that if you want to license the rights to use it for publishing books, the cost is likely to be exorbitant. I investigated the use of Garamond, but gave up when I realised it would cost me several hundred (or was that a thousand?) dollars each year.

The reason I preferred Garamond over Times Roman was that, as well as simply being a beautiful and readable typeface, remarkably, it was as tightly set or tighter. I think its readability is due to its greater "x height" (the size given to the lower case letters, basically), which makes the font appear bigger overall. But I think Gentium and Georgia are very pleasant alternatives. Google and others have also produced a large range of good typefaces for free. Whatever you choose, do check the licence to make sure you're allowed to use it for your book.

Layout

Similar to the typeface and size you choose, give careful thought to the line spacing. If you pack the lines too densely, the text will be either awful to read, or — if you get it only slightly too tight — subtly draining to read. Neither of which you want for your readers.

I made the initial mistake of using no indentation for the first line of my paragraphs, opting instead for an increased gap. Traditionally published books don't do that: they maintain a consistent and pleasant line spacing, and indent the 1st line of each paragraph.

They do this because it's just as easy to see that a new paragraph has started, but greatly reduces the number of pages required for the same text. That translates to saving more trees and lowering costs which you can pass on to your readers.

Page numbers

Unlike the eBook edition, you'll need page numbers, naturally. (Amazon will automatically strip page numbers if you have them in your .mobi file, I found, so I think it makes sense to leave them in by default). But where to place them? You can save considerable space, and reduce the page count, by including the page number in the header rather than reserving space in the footer of each page. If you do this, it's normal to place the number on the outer margin (i.e. leftmost, on left hand pages, and rightmost on right hand pages).

In the header, it's normal to alternate left and right pages with the author's name, and the book title. Sometimes in a smaller font, so it's not distracting. Leave enough space between it and the body of the page so it doesn't look like the page's text starts with the header!

Of course, you need a different page layout for left and right pages, since you need the margins to be mirror images of one another, because (generally speaking) you need more space on the edge of the page that joins the spine, simply because the pages curve in tightly together. There's nothing more irritating than not being able to read the text without splitting the book in two, or having to peer into the gutter to try to see the letters! And as well, you need to alternate Title vs Author on left and right, as well as placement of the page number if you've included it there, too.

It's worth a flip through to check that all your left hand pages use the left-hand header and footer, and likewise for the right hand pages.

Oh! And remember that page one must be a right-hand page, or you'll look like you don't know what you're doing.

Colour: text and paper

If you used some colour text for some reason in your digital edition (e.g. to make chapter titles stand out), then assuming you're opting for B&W interior the print edition, remember to change them to black.

Your printer may offer you choices of cream or white for the internal pages, and matte or glossy finish to the paper. Choose whatever you prefer, and can afford. My own taste runs to the cream colour non-glossy paper, simply because that's what looks normal to me from most paperback and hardbacks I've read (textbooks aside).

Binding

Perfect binding is not as durable as saddle-stitching, but it's far less expensive. While early generation print on demand systems had problems in durability, I think those days are long past now. The quality of print on demand books (at least, from my personal experience with Ingram Spark; as well as the claims of other printers) matches that of offset printing in massive runs. The price of each POD book is dropping slowly, too, approaching that of offset printing, but without the huge financial risk of printing thousands of books.

Incidentally, that massive up-front investment is, I think, the core reason for many, many aspects of the business model followed by the traditional publishing industry.

Table of Contents

I think it's unusual to include a table of contents in a printed book if it's fiction (the reverse is true for non fiction), but if you've given chapters interesting or descriptive names, it's not that unusual to include a ToC. And if your book is broken up into "Parts" or "Books" an abbreviated ToC listing just those is not that unusual.

PDF files for print

For the printed book, most publishers/printers want two PDF files: one for the cover design, and one for the rest of the book (the insides, if you will). PDF is a well-designed and well-understood standard, though it is complex. You need to check out what your publisher/printer wants, and follow that exactly. It's very likely they'll have a template for you to follow. They'll need to know the page count, too: the more pages, the wider the spine (and the greater the printing cost, of course). Chances are, they'll have a web page where you enter the page count, and it'll tell you how wide the spine will be.

I'll talk about the cover in a minute, but let's address a few obvious details for the PDF used for the contents: i.e. all those pages filled with the words you've slaved over.

A subtlety I hadn't observed initially was that the first page of every chapter normally omits the page number; likewise for any pages that stand between "parts" or major sections of a book. And doing this in LO is slightly tricky, since you can't change a page's style after you've introduced a page break. You need to have defined at least one page style that omits footers and/or headers (as appropriate for your placement of the page #); then you have to delete the page break, then re-insert a "Manual break..." (not Page break), this time choosing "Page Break" together with the page style you've defined for this new page.

Making the PDF files

For the contents, when using LibreOffice, this is as simple as choosing the Export to PDF option. I think it's sensible to choose 100% for the JPEG compression quality, and to only select the "Archive PDF/A-1a (ISO 19005-1)" for the PDF format, and "Export automatically inserted blank pages", for the General options: tagged PDF and bookmarks and comments are irrelevant for a printed edition. The blank pages are to ensure that the correct pages appear on the correct sheets. I think selecting that will ensure that each odd page appears on the right-hand side page, and each even page on the left — provided you're using a sensible template that has margins set correctly for the odd and even pages.

For the cover, I think you're expected to be using a Windows or MacOS system, and therefore able to use some expensive special-purpose program like Adobe InDesign or PhotoShop. My cover designer has those, and did prepare the cover, but since I didn't know the exact number of pages (which determines the thickness of the spine), I needed to adjust it later. The free software Inkscape is both reasonably easy to use, has good how-to and help information available, and produces both SVG and PDF files, and I initially chose that: a mistake, in hindsight. (Another option is The GIMP, but I personally find its UI diabolically counter-intuitive; it's probably as powerful and capable as Photoshop, but for me the learning curve was too steep. And it suffers from the same key limitation as Inkscape.)

The problem was that IngramSpark's quality-check reported the PDF files had two errors that needed correction. One was the inclusion of transparent objects (I think LibreOffice generates some spurious invisible transparent object) and also an image with low resolution (I think that was the QR code, which is just a blocky PNG image, that does not need to be high resolution). The report said that they could fix these, so I ticked the box that requested them to go ahead and do so.

Eproofs

I checked the eproofs that IngramSpark delivered to me, carefully. One awful error (mine) was a missing blank page at the very start, meaning page 1 was on the left! I fixed that quick-smart.

For the PDF for the inside contents, assuming it's all black and white, I think any kind of PDF file (in which the text is encoded as text — not as images!) should be fine. The PDF produced directly from LibreOffice is very good.

The story is very different, however, when CMYK colour is included in the picture.

Cover PDF and CMYK

For the cover, since that's going to be in colour, you need to know whether the printing/publishing company wants the artwork in the CMYK colour space used by their press (Cyan Magenta Yellow and blacK), or in RGB (Red Green Blue) as you'd want for the ebook cover.

A very brief note about CMYK vs RGB: CMYK represent "subtractive colours" produced by ink or paint absorbing light; e.g. yellow ink absorbs all visible frequencies except yellow, so that's the colour you see. Whereas RGB colours are "additive colours", used by TVs and monitors, produced by tiny glowing red, green or blue dots on the screen, emitting light. E.g. on screen, red and green together produce yellow.

And two important consequences are that 1) although both colour models produce mostly the same colours, each one also has a large number of colour that cannot be represented by the other colour model; and 2) if you put too much ink onto paper (e.g. if you had 100% cyan, 100% magenta, 100% yellow, and 100% black: a total of 400%), you end up with a "coverage" that probably exceeds what the paper will soak up, and bad things can happen: ranging from warping of the paper, colours running, or the page becoming brittle and prone to cracking. Your printer will advise you of the limits they require: e.g. the "US coated (SWOP) v2" is a common "ICC colour profile" that limits ink coverage to 240%.

Because the spine is part of the cover, and its width depends on the number of pages and on the paper stock you choose, your printing company should provide you with a template file that shows exactly where they expect the front cover, spine, and back cover to be, and their dimensions. (And inside flaps, if you're producing a wrap-around cover for a hardback.) Alternatively, they might simply tell you those dimensions: if so, you need to create the artwork to follow that exactly. As well, you'll need a barcode that represents your ISBN (often, the printing/publishing company will include that in the template they provide you). The template file they provide you will typically be a PDF (an international standard), or in InDesign (a proprietary Adobe format), or something else.

In practice, if your printer/publisher requires CMYK colours specified, this means you must generate either a file of type PDF/X (which is also called PDF/X-1a), or PDF/X-3. I believe PDF/X requires every graphic object encoded in the file to use a CMYK colour space, whereas PDF/X-3 allows objects to individually specify an RGB or a CMYK colour space.

This may be a good point to mention a couple of technical pages that argue:

  1. That printers should accept RGB and handle the conversion to CMYK themselves — see http://indesignsecrets.com/import-rgb-images-indesign-convert-cmyk-export.php (including all the comments!), and

  2. Be careful about trusting Acrobat's CMYK coverage reports — http://creativepro.com/why-you-cant-trust-acrobats-separation-preview/. Which is all well and good, but I think that may ignore some practical considerations: if your printer tells you they need PDF/X files, then they almost certainly do, and that's what you should give them.

Check with your printer/publisher: IngramSpark required a CMYK PDF file for the cover. The problem I found when I received my proof copy of the book after I used Inkscape with CMYK images to naively try to produce a "PDF with CMYK colours", was that the colours were oversaturated and also appeared to have a greenish tinge washed through it. I think this was a consequence of working with CMYK-encoded JPEG images, but saving out to a PDF file that was marked as having sRGB colour space. (Inkscape does not currently support export of CMYK PDF files.) I also had my name much too close to the edge of the cover. I needed to fix both these issues. In the meantime, though, I'd developed a most unusual problem with my Linux system, and to straighten it out I reinstalled it with a bleeding-edge version. Unfortunately, I then found that Inkscape had a bug in the conversion of CMYK JPEG images on 64-bit systems, and inverted the colours! This forced me to use the RGB images which Mirella had provided me for the ebook edition, then cross my fingers and hope for the best! It seemed to work okay for the 5"x8" edition that I released in Jan/Feb 2016, though I think even then IngramSpark warned me there might be problems.

Danger, Will Robinson!

In October, when I was preparing my 4.25"x7" (A-format) paperback edition of Wild Thing, I received a fresh report from IngramSpark that the cover was problematical: most of it exceeded the recommended 240% coverage, although it was within the 300% absolute limit for their printing presses. They advised me that they could print it, but the picture might crack due to the density of ink.

The reason this happened was that I'm using Linux as my desktop operating system (so: most software is free, bugs tend to be fixed if you report them, and you don't have to worry about viruses) but a few popular programs are not available for it. At the time, I'd been using Inkscape to prepare (crop, resize) my covers, using the artwork provided to me by my cover designer (hi, Mirella!).

But Inkscape currently can't create a PDF with a CMYK colour profile. It was not a matter of just putting a CMYK .JPG file into Inkscape and saving as PDF. And, apart from text, Inkscape also insists on rendering all objects (using the Cairo graphics engine), instead of just encoding each object for PDF and letting the PDF compositing model handle the rendering. (It probably does this so it can use the same rendering engine for screen and for creating the PDF file, so it's simpler for them.)

Scribus to the rescue

In October, with more time up my sleeve, I investigated properly. With the help of someone at IngramSpark, who very patiently answered my technical questions, I was able to work out the cause of the problem (short answer: not producing a PDF/X file), and went searching again. This time I found one free software package that does very good desktop publishing including generation of PDF/X-1a or PDF/X-3 files. It's also available for MacOS and Windows. It's called Scribus https://www.scribus.net/, has a good and comprehensive manual, and very importantly, their web site provides information on where to download "ICC colour profiles". And since IngramSpark had helpfully shown me they used "US coated (SWOP) v2", the Scribus web site made it easy to find and install that file on my system.

I won't go into the details of how to use Scribus. The key thing to know is that you draw by inserting an image frame to hold an image, or a text frame to hold text, and so on, and then import files to fill those frames with content. (Scribus also has quite a good, simple, and feature-rich text editor, although it's a little bit clunky to use.) And the 2nd key thing to note is that you need to install some ICC colour profiles before you start it up, so the option to enable Colour Management is available. You can then configure the PDF export to use one of the CMYK colour profiles you've provided. From that point, Scribus will handle the conversion of your images into the colour space you've nominated when you export to PDF. This is true even if you've turned on the option to show you when you've used colours that are "out of gamut" or too dense: converted to fit within the colour space you've chosen.

Scribus worked really, really well. It even imported the .psd (Photoshop) artwork files with the CMYK images that Mirella had provided me. I carefully read the Scribus manual first, though, and it did take me two days to learn to use it well enough to produce the new version of the cover, some new business cards, and some pamphlets.

Scribus has been pretty stable and complete as of 2012. Give it a try!

Trim, bleed, registration

Because the physical pages are trimmed after they're physically bound together to get those nice crisp edges we all love, the printer will need you to design something that includes a margin of error, since some physical movement is inevitable. These are called the trim edges, and the amount you go past the trim boundary is the bleed amount: basically, you want to put some pleasing but non-critical artwork in these areas which you won't mind losing if the cover is not cut exactly along the notionally correct edge. Don't put horizontal lines near your horizontal page edges, nor vertical lines near your vertical edges, in case it's printed very slightly askew: the narrower such a gap is, the more obvious any error in alignment will look to the human eye.

The printer may provide you a barcode graphic that represents the ISBN you have assigned to your book: position this where your publisher/printer recommends, and don't re-size it! If they don't give you the barcode image, you can get free software that will convert an ISBN to a barcode graphic. Thorpe-Bowker will also do it for you, for a small fee.

QR codes

It occurred to me it would be a good idea to include a URL in the text that pointed readers to the print edition; and to also add a QR code alongside the barcode on the cover, that simply encoded that URL for easy scanning by a smartphone. For the URL, I used Bookshow.me (as explained in "Preparing to press the "Publish" Button", under Marketing Plan) to "globalise" the URL provided by Amazon, and to generate the QR code I simply used a free Linux tool (<a href="https://launchpad.net/qreator">qreator</a>) and its graphical front-end (<a href="https://launchpad.net/qr-tools">qtqr</a>). (Later, I changed over to using a command line tool, qrencode.) I then just saved the .PNG file and pasted that into the cover design alongside the barcode provided by IngramSpark.

A problem with this approach is that it just directed people to the ebook version, not a place to reorder the print edition, but I felt that was the best choice before I knew a URL for people to buy the print editions. I had hoped I to link to them from my Amazon page; in the end, this happened automatically (I think because I spent the modest sum IngramSpark requested, to "advertise" the book). The problem with this approach is that buyers are likely to just go straight to Amazon and if they want the print edition, assume they must buy it from there. Which is fine in the US, since it can be printed there, and it's possibly okay for the UK, too, for the same reason. But in all the other countries in which IngramSpark print, so it can be shipped locally, all you're doing is leading your readers to pay more and wait longer for it to arrive.

Incidentally, you can decode a QR image you've created just as easily via the "zbarimg" tool, part of the free "zbar-tools" package on Linux. That's how I can easily tell you what I used for my reader-friendly QR code for finding the books.

After the data for the print editions rippled out into the distribution channels, a google search turned out to be a simple way to locate local booksellers who would order the book in for you if you asked (and usually, allowing online ordering). So I changed the search string to do that; and found that "qrencode" also had options that allowed me to create a 300dpi image file. So as an example, here's the command I used to generate the QR-code for Harsh Lessons, with 20pixels per QR "dot" and 300dpi resolution. Note that "%22" and "+" turn into a double-quote and a space respectively, when used in a URL:

qrencode -o QR-code-HarshLessonsBuyGoogleSearch.png --size=20 --dpi=300 \
 "https://www.google.com.au/#q=%22L.J.+Kendall%22+%22Harsh+Lessons%22+buy"

So you can see I've just encoded a string which does a Google search for ‘"L.J. Kendall"', ‘"Harsh Lessons"', and ‘buy': literally: ‘"L.J. Kendall" "Harsh Lessons" buy'.

Initially, I omitted the "buy" search term, but now that my books have gained some reviews, if I omit that qualifier the search mostly returns reviews; with "buy" included the search turns up a mix of places to buy the book, and reviews — and that seems good to me.

Business stuff

Proof copy

Ahhh, the joy of receiving your baby in physical form! Yes, order a proof copy. Then give it yet another proof read. I find that each time I read my book in a new mode, I see different errors. (I check it first on my desktop's screen; then as a PDF loaded onto a tablet; then printed on paper as A5 booklets stapled in groups of 16 sheets; then the real book). You could probably avoid all that by paying for a professional proofread/copy-edit! Anyway, I found several more small continuity errors, several typos, and decided to change to US-style punctuation for dialogue (the punctuation goes inside the quotation, instead of treating the quotation as a thing-in-itself), and about 150 sentence-level tweaks to slightly improve wording or clarity. It's funny what you see when you're holding a physical, printed book. I also noticed that some chapter titles had abnormally-little spacing below: I tracked this down to reducing the line spacing for the entries in the Table of Contents (which were still marked as Level 1 Headings), and this somehow carried over to a few of the chapter titles I had edited here and there through the book.

I'm also so glad I opted for the cream coloured paper rather than white. And I was enormously happy with the Georgia font, which is wonderfully easy to read, with much larger x-heights than Times Roman at the same nominal point size.

Launch date

At some date your book will be ready to go on sale. Allow enough time for your book's publication information to filter out into the sales channels. Book sellers keep databases of books available, indexed by ISBN and other details. I don't know the details about how the meta-data for your book is disseminated so it lands in these databases, but what I did was provide all the required information to the ISBN provider (in my case, in Australia, this was Thorpe-Bowker), and similar kind of information for the Cataloguing-In-Print people in the government. In addition, the printer/distributor IngramSpark offer an option to "advertise" your book: my guess is that they push the information out to all their partners, too. I think I set a date three weeks after I felt the book would be ready. I really have little idea what the ideal period of time would be!

Registering your copyright

In my earlier article, I thought the national body for managing and recording copyright in Australia was the <a href="https://members.copyright.com.au/">COPYRIGHT AGENCY</a>. Their website states "We're a not-for-profit that provides simple licensing solutions to allow you to use copyright-protected words and images. Fees from licences are paid to our creator members." And adds "Our core function is to license users of copyright material to make reproductions and communications of copyright works under appropriate provisions of the Copyright Act 1968, and to distribute money collected fairly and equitably to copyright owners and creators."

There's also the Australian Copyright Council, http://www.copyright.org.au/, which seems similar; but they seem to be independent.

I think they're more related to allowing some fair use reproduction of copyright material under license, with some compensation paid to members than with lending rights. I think I was getting confused with the government organisation related to lending books in public libraries and institutions.

Lending Rights (ELR/PLR)

If libraries buy books, they make some payments that are collected and apportioned fairly to the authors of the books. By registering each of your printed books with the government's lending rights organisation (in Australia, this is https://www.arts.gov.au/funding-and-support/lending-rights), you give yourself the chance to be paid, should any libraries opt to buy your books for their shelves.

So, provide all the information for your book; and as you publish more books, remember to return to the copyright agency and register the new books. If your book does get included in some libraries, then you might earn some small income through a scheme set up for that purpose. To be eligible, though, you need to apply for and Electronic and/or Publisher Lending Rights: ELR and/or PLR. In Australia, it's a straightforward process which is open to indie and self-publishers, but only for print books (not for ebooks).

If you're self-published, you should apply and register for each of your books as both Creator and Publisher. If indie published, then obviously you only apply as the creator (your publisher should apply for the publisher rights). And you should specify the royalty split just as you have agreed with your publisher. Contact them via their web site, and they should provide you a "Claimant No." and corresponding password as a creator (and a separate claimant number and password if you're also a publisher). Then you need to login (at https://lendingrights.arts.gov.au/lendingrights/) and provide all the required details for your printed book(s) as creator (and again, separately as publisher, if you're self-published: logging out as creator then back in as the publisher).

Obviously this is an optional step, and perhaps even an overly optimistic one. But, who knows?

LCCN

The US assigns a Library of Congress Catalog Number to each book it holds a copy of. Most other countries use the Cataloguing-In-Print record: see below. For an LCCN, the picture is different: whether a book is accepted into the Library of Congress is up to their librarians. And I believe you can't obtain it after the book is published. Nor does it make much difference to you as an author, I believe. Reports also seem to vary about whether indie publishers are accepted or not. But instead, in the US you might consider obtaining a PCN (Pre-assigned Control Number). Again, I think this is easy and cheap or even free to apply for: beware of companies offering to sell or obtain an LCCN or PCN for you.

I gather that if a librarian anywhere in the world decides they'd like your book in their library, they'll search their databases: if they find it, they'll use that entry (maybe tweaking it); if they don't, then they may type up an entry and add it into the database, where it can be seen by everyone. I think the key advantage of doing it yourself is:

  1. You save a librarian a few minutes work, and

  2. You probably have a better idea of the categories your book falls into than a librarian who may not have yet read your book.

That's all.

CIP/PCN

This isn't a number: it's a block of text with human-readable fields that you can request from your National Library Association. It's used by librarians to help find books. I think it's well worthwhile obtaining a CIP: the only cost is that you are obligated to provide a print copy of your book to your national library.

Categorising your book

When applying for the CIP (or PCN), the national body's website (in Australia: Thorpe-Bowker) will present you with online forms which you simply fill in. As part of that, they'll provide an option to choose the categories and sub-categories that best describe your book. It makes good sense to do this honestly and with careful thought. The hierarchy of categories is quite deep. I suspect doing this may improve the discoverability of your book in the databases accessed by book stores, and through more general online search engines.

When you fill in the required information on the Thorpe-Bowker site after logging in, they provide options to set the Primary Subject and Secondary. For The Leeth Dossier, I've as the general themes I selected Fiction — Science Fiction General and Fiction — Fantasy General. It's in these tabs that you fill out details such as whether it's an ebook or a print edition, including format/size. After that, you can drill down to provide a much more detailed categorisation. The hierarchy is long and goes down to about five levels in some areas: I expect it ties into the Dewey Decimal classification system.

You can and should use exactly the same categories for the print edition and an ebook edition. It might be wise to make a note of the categories you've identified, when you first do it, to make it easier to pick the same categories for the other edition. But it also pays to have a browse around the category hierarchy to double-check you haven't omitted an important category.

I noticed I hadn't updated my Thorpe-Bowker ISBNs with the details for the planned 4"x7" edition. Thorpe-Bowker make it easy to copy the edition details to a new ISBN via their "clone" button: after clicking on that, you simply select the ISBN that you want the details copied into, and then you're presented with a page to make the changes needed to distinguish this edition from the others. Two oddities I noticed here: even though Wild Thing is Volume 1 in the series, and there is an option to provide information about the volume no. when a book is part of a series, if you choose that option, it won't allow you to enter a "1" to say it's the first volume. And if you leave it blank, it complains that you must provide a number greater than 1. So I don't see how you can tell Thorpe-Bowker that a book is volume 1. And if your book has no illustrations (not counting the title), then you can't enter "0" for number of illustrations, you have to leave it blank. Go figure: perhaps they need a usability expert to give their website a slight overhaul. It's very workable and functional, all the same, and that's the main thing.

Money

You also need to put some careful thought into the price to charge for your print edition, when it will be released, and so on. A particularly important decision here is the discount you will give book stores, and whether you will allow "returns".

Money (returns)

To manage the financial risk a book store will only stock a book, if the publisher allows "returns": that is, after a time, the store may return unsold copies to the publisher and be refunded the cost of the books. But as well, the publisher (not the store) will pay the return shipping cost. (Sometimes, if it's cheaper to destroy unsold copies than return them, the agreement may allow that, instead.)

For a self-publisher, allowing "returns" could be a costly mistake, unless you have a massive readership. So it's far safer to disallow returns. The downside is that few book stores will stock your book. (Some, more flexible, may decide to do so: ordering small numbers as long as it sells, and taking the risk that if people stop buying it, they'll have to sell off any remaining copies at a discount, or just get rid of it. And then, probably stop ordering any more.)

But the book should still make its way into the databases, and should turn up as able to be ordered on demand from book stores.

Pricing (discount)

To have any chance at all of your book being ordered by book stores, they need to be able to make a profit in doing so. This will be easier if they order more than one copy, since the processing and delivery cost will be spread over several books, instead of concentrated in just one. But if they prefer just to order a single copy when a customer orders your book, they'll need to cover the delivery and their own internal costs. For these reasons, you need to provide a discount for book stores. This ranges from 30% to 55%, typically. The higher the discount, the more attractive your book will be to the stores; but the less you make.

I can't advise you on that, other than to say, think about it carefully, look at what similar books cost, and discuss it with friends who understand business and sales. But do protect yourself: don't set the price so low that you lose money by selling your book!

Nor can I advise you on pricing or number of copies if you opt for offset printing of a single initial print run. Just be aware that you'll need to store all the books you ordered, and pay for the postage as you sell each one, and spend time addressing and mailing them (or delivering them in bulk to resellers), and dealing with problems if books go missing in transit. Personally, I'm very happy to be using print on demand and leaving it to Ingram Spark to handle all that for me. It gives me more time for writing.

Here's a useful URL, although it doesn't cover the topic of setting the price: http://mediashift.org/2013/05/the-real-costs-of-self-publishing-book/

And here's a longer article that covers different ground to that article, and to this one too — though there's some overlap — Duke Diercks's 1st person account of self-publishing tips and costs. Check it out, it's well worth a read. I'm not sure I agree with the idea of paying someone else to apply for your (P)CIP, but leaving that one exception aside, there are some real gems in there — like the idea about selling into small book-stores! I think Duke's article is actually more digestible than this whopper of a post.

Dates

You need to decide a release date, too: don't set all this up the night before the book is first available for printing. Traditional publishers handle this very well, with carefully planned marketing campaigns before the release date, all with the aim of getting as many sales as possible when the book is released. Of course, the down side is that for the vast majority of traditionally published authors, this marketing campaign will be a one week or two week effort that runs once only, ever. In contrast, for an indie author who has chosen print on demand, your book will always be available and it's up to you how you choose to market it as well as how long for.

Review copies

In many ways, it's much easier and cheaper to send ebooks to people for review, but professional reviewers for traditionally published books (such as in major newspapers and magazines), tend to prefer a free printed copy, though of course there's no guarantee they'll write a review at all. Their time, after all, is precious. But at least with a print edition you have a chance of that happening, which — if the review is positive! — could lead to a big success for you.

Put care and effort into this, though: do your research to find what kind of books different reviewers prefer, and only send your book to someone who might appreciate it. And obviously, any note you send along with your review (a press release) should be as clear and succinct and as useful to the reviewer as possible. But this topic is now leading into the general area of marketing, at which I'm still very much a novice, as well as drifting off topic for this post.

National library

Remember to send off a print copy of your book to your national library, if you received a CIP or PCN (or LCCN)!

Tell people

From the contacts list you've created, send out the information to each group. Then follow through on your marketing plan.

Summary

Prepare the cover and content PDF files for your book as carefully as you can, to make the book as readable and beautiful as you can; make sure you buy and assign an ISBN to it; register the book with the appropriate bodies; check your work carefully after you've done each piece of it; and carefully categorise your book and make it easy for potential readers to find it.

And then, give yourself a well-earned pat on the back, relax for a little while. When the creative energies return, dive back in to the writing. With any luck, your readers will be demanding it, and writing good new books is the best way to develop a body of work that may also earn you an income.

Good luck!

Posted by at 10 comments:
Labels: , , , , , , , , , , , , , , , ,

Tuesday, 12 January 2016

Adventure #1 in publishing: Creating the ebook!

Ebook conversion.

Hoo, boy! This should be the easy step, but I think this is where most of my effort went, in the ten days before my publication deadline. You need to convert your book to the ebook format required for the publishing platform you've chosen. This should be straightforward and painless, but I'm told it's anything but. My early experiments bore that out: but read on, I found a good and simple approach using Calibre.

Lest this sound a bit scary, I should cut to the chase and say that once you've cleaned up your source document, and entered the metadata into Calibre for your book (by typing in the blurb, ISBN, title, author, etc.), the conversion to epub or Amazon's .mobi using Calibre requires only a few minutes of effort, and produces a good and reliable result.

What you want is the ebook format to be as nicely laid out and as well-formatted as what you have in your word processor. But for a various reasons, the conversion can have major problems.

I was using LibreOffice 5.0.3 for my word processor, incidentally, at the time I wrote this blog post. Most people probably use Microsoft Word. A few people (especially if they're producing something like a photo book or a children's illustrated story) might use InDesign. I think InDesign is poorly suited to producing a reflowable ebook: InDesign is, after all, designed to do the opposite, to place each piece of text and artwork exactly where you put it, and not to be movable or resizeable. (That said, it would be great for non-reflowable ebooks, like children's picture books or coffee-table books with lots of images.)

In contrast, one of the biggest strengths of an ebook is that the reader can enlarge or reduce the font (or possibly change the font completely), to suit their eyes and/or the lighting conditions. So this means that you have to be careful about preparing your MS so this reader-directed reformatting can work well: you need to use true page breaks when you want a new page, and an indent or centring style when you want to indent or centre something. An awful mistake is to use spaces/tabs and blank lines to manually position some text so it looks right for you in your MS. Likewise, it's a bad mistake to make a piece of text look like a chapter title but not mark it as such. In short, you should be using paragraph styles exclusively. Doing so also means that if you decide you need to make a change to how you've laid out every instance of something, you need only change the paragraph style, not each paragraph!

Here are some problems I've encountered, using LibreOffice:

The HTML it produces is far more complex than it needs to be. I have basically two kinds of paragraphs (body text and chapter titles), and a few pieces of text that must be centred. I use italics for emphasis. But LO (currently) splits the runs of text into shorter spans of differently-named but identical styles (usually, showing where I went in and edited the text), and for my MS produced literally thousands of paragraph styles.

Worst problem for me was when I copied the whole MS into the new template I wanted to use: after resetting all the paragraphs to the correct body text style, and setting all the chapter titles to the chapter title style, it lost (randomly as far as I could see) about half the places where I'd applied the italic style. I delved into the XML and after a days work of writing some programs, was able to recover about 90% of the italics. The rest I just had to notice and re-do manually during one of my many read-throughs.

Conversion to Microsoft docx and back seemed to help somewhat: but then other aspects of the page formatting got messed up (left and right margins, footers, etc.). So that was a dead-end.

The table of contents generated for the ebook format was just bizarre. You don't want page numbers matched to chapters in the TOC, since page numbers basically don't exist in the ebook format (because the ereaders don't want to calculate this up-front and store and display the information: the technology may change in future). Anyway, not only did my chapters have page numbers, but after conversion, each chapter in the TOC occupied a separate page. Ouch!

Loading up the LibreOffice .odt file into Calibre for conversion also produced poorish results when I then used Calibre (v2.45) to convert it to epub and Kindle (.mobi) format. Calibre seemed to work better when I saved as a .docx and then loaded that up. But the formatting wasn't what I wanted, so more investigation was needed. I made this note to myself when I started this step:

"I have some notes on a page at Goodreads about tips for conversion to ebook formats, and a few web pages to read, as well as my own experiments to perform. Worst case, I may have to unzip the epub format and have a look at the raw HTML, and simplify it down to the bare minimum. This is not meant to be rocket science, after all."
(Which is what happened, incidentally.)

Oh, I also had a plug-in for LO that converted straight to ebook formats: but that seemed to have its own problems, so I uninstalled it.

Here's a very good explanation of self-publishing on Kindle.

Now, at this point I could have delved into the HTML side of things, since Kindle uses a subset of HTML as one of the possible input file formats for producing a book. (The others are PDF and mobi.) If you want to delve in and get your hands dirty, and take control of lots of aspects of the layout, then learning about the HTML may be the best approach. I didn't do that in the end, but rather than ignore all the tips I've gathered, I'll stick them in an "appendix" after this main article ("Kindle's HTML").###Fix this link

The approach I took in the end was much simpler, and I believe generally more useful, and should only continue to improve with time, so I'll focus mainly on that.

My approach was to rely on Calibre, since one of Calibre's important main functions is to perform ebook conversions.

I thought the best starting point was probably to see what it produced, and to look into any problems I found. In that way, if I found something that looked like a genuine problem in Calibre, I could inform its creator, Kovid Goyal. Or, it might point to problems in what I'd done.

Importing my .odt file and converting to epub was painless, as was reading the resulting epub version within Calibre – but I noticed quite a few issues. Here's a screen shot of Calibre in action, with Wild Thing imported into it:

Calibre is powerful, flexible, and has a well thought out user interface that makes it pleasant to use. But the flexibility (necessary to deal with all the different tasks it can perform), meant that I found myself at a bit of a loss as to work out what to do. Calibre also comes with lots of good documentation, including video demos.

Another thing I found was that Calibre itself has what looks like an excellent editor built in, with a well-written user manual available for free here. (I did what I normally do: "printed" the web page to a PDF file, then opened it in Adobe's "acroread" program, selected "booklet" printing, and sent that to the printer, stapling the result with my long-arm stapler to make a convenient A5 reference booklet for easy reference.) Obviously, editing the MS in Calibre is a last resort: if I make changes to the original MS and re-convert in Calibre, I'd need to make any edit in Calibre again – or else make the Calibre version the main source file for the book, which wouldn't be a good idea since then I'd have different "source file" for the print and the epub editions.

The trouble for me was that my deadline was now so close I simply didn't have the time to study and learn Calibre thoroughly. I needed some shortcuts.

Because I'm technical, I decided to poke about under the bonnet and see if I could work out what was happening. Now, most of this poking about was unnecessary and is merely a distraction: so I'm again going to put most of it into yet another "appendix" to this article ("Poking about in Calibre").###Fix this link, too

But one aspect of it proved so useful that I'll shortly describe some of my poking about, within this article proper.

The ".epub" file is actually a ZIP file with specific files and file formats inside it (that's good design!). One of the intentional consequences of this is that you can poke about inside. If you know what you're doing, and don't break the rules, you can even change things. (You just zip it all back up into an .epub file again.)

So I poked about and spent a while developing some scripts to try to fix what I saw as problems, and continued delving into and learning the technical details of how the .epub format worked, and what Calibre produced. I made some progress, but then reached a point where things looked sufficiently wrong that I filled in a bug report to describe what I was experiencing.

The three big errors I had were:

  1. After importing my LibreOffice MS into Calibre and converting to epub, the Table of Contents (of about 70 chapters), appeared as one separate line on each page: you have to page forward through 70 pages to get to the actual 1st page. Or, if you wanted to "jump" to chapter N, then you have to page forward N-1 to get to the ToC entry for Chapter N, and then click on the link.

  2. I was getting white square rectangles appearing for some of the non-breaking space characters when I uploaded the .mobi file to KDP.

  3. Lots more fonts than I expected in the output file, leading to strange changes in the paragraphs.

The developer of Calibre, Kovid Goyal, was very helpful. And, the executive summary of the long and detailed description of my trials and tribulations are that all the problems were caused by either a wrong setting I'd chosen in Calibre, or a genuine bit of messiness in my MS.

To fix problem (1), Kovid pointed out two simple corrections to what I was choosing for the conversion operation:

  1. He recommended converting from .odt to .docx format , and give Calibre the .docx file, since a lot more work had gone into the conversion from .docx. So I chose "Save a copy" as .docx and tried that.

  2. In the Structure Detection section of the conversion dialogue, either change the "chapter mark" to none, or change the chapter detection expression to "/". So I set the "Chapter mark" to "none", and also changed both the "Detect Chapters at" and the "Insert Page Breaks before" to just a "/" (this means, "disable this function").

Together, those two pieces of advice fixed pretty much all the errors I'd found in the conversion process – apart from errors obviously coming from my MS itself. Here's another screen shot, showing all three (changed) settings in Calibre:

For problem (2), it turned out to be a character I was occasionally (accidentally) somehow typing instead of a non-breaking space, in LibreOffice. The character appeared to be a non-breaking space in LO but was illegal for Kindle (specifically, it was the Unicode character U+FFF9). I just had to find and delete all those characters from my MS.

Problem (3) – fun with fonts! When I paged through the ebook in Calibre, doing a visual check, I noticed there were some sections in the wrong font. Checking back into the MS I found that, sure enough, there was a genuine font change in the MS – with a visual difference so small that it was almost undetectable in LibreOffice. But then I realised that finding all these by visual inspection (i.e., manually) was an unnecessarily laborious way of finding and fixing them. By manual inspection, I had learned that the font errors so far had been because some of the text was still in Garamond 9pt. Because Garamond is not installed on my system and the license costs for me to acquire it and pay the annual fees were prohibitive, I had changed the body-text paragraph style to Georgia 10.5pt. Anyway, the odd slippage back into Garamond 9pt would have happened because I must have done some manual formatting, so that when I changed the font style within the paragraph style, those manually-applied formatting changes persisted.

So I called up the Find&Replace dialogue, clicked on Format, and then on the Fonts tab. Now, since Garamond isn't installed, I couldn't pick it from the list. However (and this is really praiseworthy on the LO developers' parts), I was able to type Garamond (with leading cap) into the font text field, choose "Regular expressions, and then enter ".*" (no apostrophes, naturally) into the Search field.

Now, I could fix them one by one, by clearing direct formatting, after noting whether the text should be italic or not, and then setting it italic as needed, after clearing direct formatting. But that, too, was tedious. Useful to do a little, though, to get a feel for the errors and start correcting them.

I could see exactly how it had happened, and it had made sense at the time, but it did have this side-effect that I'd been unaware of. Anyway, understanding the types of errors, I then did a Find All (such a cool LO feature: you end up with multiple separate selections of the matching pattern throughout the document, so you can make changes to those pieces of text in one operation). LO told me it had 299 words and 1,457 characters selected, and I noted that the font size was 9pt in every case (by simply observing that "9" showed in the font size box on the main menu-bar), and then changed the font to Georgia and the point size to 10.5, and that was that!

(Except for LO bug 62603 – aarghh!)

The joy of the "stylesheet.css" file. I thought I'd do a search for other typefaces that might have crept in (Arial, Calibri, Times Roman). I found that there were a few places I'd unintentionally slipped into Times New Roman. Then I realised I could see every single font I had actually used just by looking inside the "stylesheet.css" file inside the .epub file.

And, yes, there were a whole bunch more there. Here's the list, for maximum self-embarrassment: 

$ grep "font-family" WildThing-exp5.unz/stylesheet.css | sort -u
    font-family: "Liberation Sans", Arial;
    font-family: "Liberation Serif", serif;
    font-family: "Times New Roman";
    font-family: Calibri;
    font-family: Garamond, sans-serif;
    font-family: Georgia1, serif;
    font-family: Georgia;
    font-family: Times New Roman1, sans-serif;
    font-family: Ubuntu, sans-serif;

Actually, I couldn't make much sense of what was going on when I searched for Liberation Serif: it seemed like a high percentage of paragraphs in the document were in this font: I could clear the formatting so they weren't found, but doing so made no visible difference. And these weren't paragraphs that had proven to be a problem in the conversion. I wondered if some weird font substitution was still going on? The particularly weird thing was that these searches would also find the chapter and part headings – but when they were selected, the font showed as Times New Roman, not Liberation Serif. Yet when I'd searched for Times Roman, they hadn't shown up. (The only pieces of text in the whole MS in Times New Roman were the title and "by L. J. Kendall" on the title page. Because of a bug (feature?) in LO's ToC generation, I had had to add a space character to the end of each chapter title (to make the chapter names actually appear in the ToC). Because of that work around, it seemed like these were all appearing in Liberation Serif. Finding and fixing these was tedious. I couldn't do a Search& Replace because the word "Chapter" and the chapter number were supplied from the paragraph style (they weren't "in" the document body). It turned out that the text is provided via the Bullets and Numbering dialogue's Options tab; the font is kind of defined by the "Character Style" you choose; but I couldn't at first see where these character styles were defined (or modifiable). It was set to "None"; when I changed it to "Header Char", it changed to Liberation Serif, even though it appeared as Time New Roman because that was the font style defined for the Chapter Title style defined in the "Styles and Formatting" dialogue. A bit confusing, eh?

So, in the "Styles and Formatting" dialogue I needed to select the "Character Styles" section, and then change that to Liberation Serif. While there, I set the font size and colour, too. That changed all the auto-formatted chapter titles to be the same: I changed the Character Style for the Prolog to match, but chose not to do so for the Parts nor the Acknowledgement, nor Afterword etc.

So, I checked that after making that change, I checked to see if the "added space" to the title was still being detected as in Liberation Serif when I did my Find&Replace: it was, but I figured that since this was a non-printing character, letting it be changed to Georgia shouldn't make a visible difference. So I went ahead and did a Find All for the Liberation Serif font: this time, it worked harder, finding I think 66,000 words in that font. So I went ahead and changed the font to Georgia, and the font size to 10.5 for all of them. That seemed to make no visible difference, but now when I searched for Liberation Serif, there were no matches.

Whew!

Okay, next on the list of probably-spurious fonts was Liberation Sans: that found only the Acknowledgement and Table of Contents headings – good!

I then checked the others – none of them were used, except for Ubuntu in four places. So, after that, it seemed that I had (finally!) cleaned up my font mess. Oh: and in the Find&Replace dialogue I clicked on the "No format" button to clear the search for font, and also unchecked the regular-expression, so as not to accidentally confuse myself the next time I used the dialogue.

In Calibre, you update the book by choosing "Add files to selected book records" from the Add books menu, and then selecting the (preferably .docx file) for your MS.

I noticed some odd justification; checking back, I discovered that my two-space pedantry had come undone: all the occurrences of a non-breaking space followed by a normal space, between sentences, had been lost somehow. A quick regular expression Find& Replace fixed that. Oh, and for some reason, every paragraph was no longer fully-justified. Re-converting fixed not just the weird spacing problem but also the justification problem. Now all that remained was trying to work out how to centre the chapter headings for the auto-titled chapters (and ideally, add a little space below).

Ha – in checking, I found that the back cover image I'd inserted on the last page, and anchored to the page, had stayed on that page even when the font change had increased the number of pages. It now appeared about 50 pages before the end. So I fixed that, too.

After that, "all" that was required was about half a day of intense and error-prone work to find the single-character "smearing" of regular-into-italics and italics-into-regular caused throughout the MS in every place where there had been a style-change at the edge of where a Find&Replace had operated.

Sigh. But at least that was the last of my problems, and things proceeded smoothly from there.

Okay – once again, this blog post has turned out to be much longer than I expected, so I'll need yet another separate and new post to cover the topic of the nitty gritty of uploading the file to Kindle and making your Amazon Author page and making updates. So I'll leave it there, for today. Stay tuned!

A Nice Table of Contents

Oh, one thing I did to make the Table of Contents nicer was to delete the leader-characters and page numbers from the auto-generated table of contents, leaving just the (useful) hyperlinks for the ebook edition. I've also found a problem, due to LibreOffice's bad habit of breaking runs of characters into separate logical spans of text. This means that if you edit any text in your ToC, and new text you type in will be in a separate text span. This was very visible because I'd chosen a colour for my ebook chapter titles (not plain black), so edits became very visible, as thed edit was in black and the auto-generated text was blue.

Editing the ToC manually to delete the leader characters (the row of dots) and the page number reference (mostly useless in an ebook), after the 1st time, instead of doing it manually, I used the Find&Replace dialogue: I turned on the Other Options, selected Regular Expressions, put nothing in the Replace With field and this text (without the quotes) in the Search For field: "\[0-9][0-9]*", and then quickly replaced each one.

Poking about in Calibre and .epub

So I copied the .epub file Calibre had produced, into a temporary directory to play with. The 1st step was to unzip the .epub file. Now, I noticed there were far more "index_split" files than there were chapters, and so I opened the first few of these files, and the content.opf, page_styles.css, titlepage.xhtml, and toc.ncx files. I immediately noticed a few unexpected things: text was still being broken up into some very short runs of characters, with different paragraph styles for each run. When I got to the stylesheet.css file, things started becoming clearer. That file defines all the paragraph styles in a very human-readable format, and it became obvious that I apparently had sections of text that looked the same, but which weren't. Since the paragraph style names created by Calibre are pretty distinct (like p-p1, p-p2 and so forth), it meant it would be easy to search the html files to see where they were used. In that way, I could find where I'd used these odd styles, and change the original MS to remove the weird styling.

Now, the 1st problem in my epub version is that Table of Contents (TOC) puts each line of the TOC on a separate page! Looking in the toc.ncx file, I see it looks like this: 

<navPoint id="ujwaAQQK4di35KOrpmPFchB" playOrder="1">
      <navLabel>
        <text>Prolog 1</text>
      </navLabel>
      <content src="index_split_004.xhtml"/>
    </navPoint>
    <navPoint id="utE7axnMMjYH5AzmPYfyOp2" playOrder="2">
      <navLabel>
        <text>Part I 14</text>
      </navLabel>
      <content src="index_split_005.xhtml"/>
    </navPoint>
    <navPoint id="uyHLH5SBCmIBt42iiswSe24" playOrder="3">
      <navLabel>
        <text>Chapter 1 15</text>
      </navLabel>
      <content src="index_split_006.xhtml"/>
    </navPoint>

So it looks like the page-breaks must be inside the actual content files like "index_split_004.xhtml". Looking inside that shows that the text is "Prolog 1" as you'd expect, but that instead of being a normal paragraph, it's defined to be a header element (H1). That seems odd. Look: 

<h1 class="p-p18" id="calibre_toc_2">
   <a href="index_split_075.xhtml#anchor8" class="s-t">
       <span class="s-t4">Prolog 1</span>
  </a>
  <a id="anchor9" class="s-t"></a>
  <a class="s-t"></a>
</h1>

Another odd thing there is that there are three anchor points: the 1st with the text "Prolog 1" and ID "anchor8", a 2nd with no text/content but an ID of "anchor9", and a 3rd with, again, no text/content, all the empty anchors with class "s-t", the "Prolog 1" text with styles-t4. I don't understand that. Looking again at the stylesheet.css, I see that the "s-t" class defines a style with 0 margin, 0 padding, and a 1.2 line-height, and s-t4 is the same but with font-height 0.77419em.

Ahhh...! Perhaps because I manually reformatted the main block of the TOC to be 9pt, and the PARTs to be 10pt? And the 1st anchor is for the left text, the middle for the leader/spacing dots (omitted) and the 3rd for the page number? Sounds plausible, except the page number is in the 1st anchor, not the 3rd. Hmm. It kind of matches the definition at http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element which says that if you leave out the actual link, "then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents." So: why is the page number inside the 1st anchor, not the 3rd? The anchors are often used to indicate clickable content.

What is a class, anyway? Sitepoint says that an HTML element's name (like "h1" or "div" or "a" or "p" specifies headier, division, anchor and paragraph), the "class" attribute let's you specify one or more subtypes. These subtypes are used to label semantically-similar things for identification, so that CSS or JavaScript code can then do clever stuff like define some properties or do something to all elements in the whole document structure (DOM) that have that subtype.

It also means that if I want to auto-remove the page numbers from the TOC entries, I may have to remove it from both the index_split_004.xhtml file and the toc.ncx file – something to keep in mind. So: does this mean I should manually delete the TOC from the MS and regenerate one with page numbers turned off? Or write a script to do the edits, so I can keep a single MS file? Or maybe insert two TOCs, one designed for epub and one for print, and write a script to delete one or the other depending on whether I'm generating an ebook or a pbook? Or, is there a tweak in Calibre itself I could do? If you click on "Convert books" and then on the "Structure Detection" button, it shows you the code it uses to "Detect chapters" (which looks perfect to me), and also to"Insert page breaks", which again looks good, and explains where the 1-page-per-TOC-line problem is coming from: each line is of style "H1", so it's of course getting a page break.

So it sounds like a 1st step might be just to regenerate the TOC in the MS, and not fiddle at all with the formatting, and then see what Calibre produces.

Ah, and I see in Calibre's "Heuristic Processing" conversion option, one that says "Renumber sequences of <h1> or <h2> tags to prevent splitting" – that sounds like what I want, so the problem may become very simple to solve. Hmm: nope. It now has two lines of the TOC per page! An improvement but not a solution.

Oh, and while fiddling with fonts, noticed the paragraph indent was an absolute unit of measurement (cm) instead of relative (points). So:

To change the measurement units used in this dialogue, choose Tools - Options - LibreOffice Writer - General, and then select a new measurement unit in the Settings area.

Hmm, tried again after fixing up far more font-change issues than I expected: I did have several messes. Now, it's all in Georgia, 10.5pt. TOC still wrong. Changed an option to force it to use the auto-generated TOC – I assume that means the one in the .odt file…

"Appendix – Kindle's HTML"

Most of the text below (apart from the occasional editorial remark in italics) is directly quoted from the Support Indie Authors forum on Goodreads.

Never specify fonts or font sizes.

Use percents for indents and em's for margins.

Limit use of symbol characters (try to use HTML symbol codes) and in-line formatting. (We only use bold and italics -- not even super and subscripts.)

But Morris noted (good tips here http://www.morrisegraham.com/):

You can, and should specify font sizes for chapter and title headings. This is done by specifying size in the style part of your header by using a CSS style.

Like.... 

p.h1
{
font-size: 1.5em;
text-indent: 0em;
text-align: center;
font-weight: bold
}

note that when I use an h1 header in my body, it causes the text to be 1.5 em, which is 1.5 times the width of the letter "m." So when the customer on the end adjust font size in their ereader device, the titles and chapter headings stay relative in ratio and proportion to the deafult font size. You can only get this kind of control by doing your book in notepad and then converting it to eBook with a converter later.

But Owen then noted:

If H1, H2, H3 etc tags are used, each device will display them in their own different default size. You can of course define your own styles and adjust the sizes if you want to, but we've always been happy with the defaults.

Micah noted:

One thing that always bugged me about the KDP defaults is that they automatically stick a huge extra line of space between paragraphs. This makes intentional section breaks very difficult for the reader to interpret. To avoid Kindle sticking in extra space, you do this (presumably in the CSS section):

I just define the normal paragraph properties: 

p
{
text-indent: 1.3em;
margin-bottom: 0.2em;
}

I found that setting the bottom margin to 0 seemed a bit too tight, and also thought the default text indent was too large for most eReaders. But you can adjust them as you like.

And he added:

Oh, and another thing which I find a bit odd about Amazon's eBook formatting: if you do not hard code in justified text, Kindle eReaders will justify the text by default.

That's not an issue, however what may be an issue is that this default justification does NOT show up in their Look Inside feature.

I have not hard coded justified text, so in the Look Inside preview, it appears as if my books have left justified text. But in an actual eReader they show up with fully justified text.

Owen shared lots of good info:

In our case, we specify a "normal" style in our style sheet for all normal text that is: 

p.Normal, li.Normal
{margin-top:.60em;
margin-right:0;
margin-bottom:0;
margin-left:0; 
text-indent:5%;
}

Our paragraph style (which is hardly ever used) is: 

p
{margin-top:0;
margin-right:0;
margin-bottom:0;
margin-left:0; 
}

Our heading styles follow this format: 

h1
{margin-top:2em;
margin-right:0;
margin-bottom:.30em;
margin-left:0;
border:none;
padding:0; 
font-weight:bold;
}
h2
{margin-top:0.6em;
margin-right:0;
margin-bottom:0;
margin-left:0;
border:none;
padding:0;
text-transform:uppercase;
font-weight:bold;
}

h3
{margin-top:0.6em;
margin-right:0;
margin-bottom:0;
margin-left:0;
border:none;
padding:0;
font-weight:bold;
}

h4, h5, h6
{margin-top:0.6em;
margin-right:0;
margin-bottom:0.6em;
margin-left:0; 
text-align:right; 
font-weight:normal;
font-style:italic;
}

We've never set the text justification manually. I was unaware until Micah mentioned it that anyone would think this "unprofessional", since I would have thought that readers of eBooks would be aware that the Amazon "Look inside" feature formats things differently than eReaders. I don't think I want such people reading our books anyway (our characters often speak and act "unprofessionally" and that might annoy them?)

I have read that some readers find left justified text easier to reader. I suppose there might be some worth in not hard-coding the justification in case their device allows them to select that option?

And also:

Igzy wrote: "If it's not too much trouble could one of you offer an example of two properly formatted paragraphs laid out together? I'd be much obliged if I could see the tags in action, as I'm not familiar with HTML formatting. "

No problem. Of course GR interprets HTML code, so this example used parentheses in place of pointy brackets, thus ( = < and ) = > . This is how we begin a chapter, with notes after the ||:

(br clear=all style='page-break-before:always') || This tells the Kindle converter to break the page. Below are the headings: heading 3 for the main, and heading 4 for the sub, which is italic and aligned right.

(h3)(a name="_Toc410049128")Prologue: Zero Day(/a)(/h3) || name ID's the target for the TOC link.

(h4)Janin Station;(br) || br is a linefeed (line break)

Tau Verde, Vulpecula Region(/h4)

(p class=NormalBlock)It was make-and-mend day for the Halith Imperial Navy’s Kerberos Fleet ... ruled the lives of Halith mariners—especially when the fleet was lying up at a comfortable port like Janin. (/p) || This a paragraph container. HTML designates the beginning of a container with a code, just p here -- h3 above -- and ends it with a / in front of the code: /p. "class" defines the type of paragraph as defined in the style sheet. The is flush-left paragraph with extra space at the top. The CSS entry for it is below. 

(p class=Normal)Watchstanding and sensor sweeps ... guarded by a ring of monitors. (/p) || This is a standard text paragraph. 


p.NormalBlock
margin-top:2.5em; || creates the extra space. Note there is no text indent. 
margin-right:0;
margin-bottom:0;
margin-left:0; 
}

That is 90% of an HTML text doc right there (with the CSS examples above, in the previous posts). Yes, you see a lot of godawful gibberish in the code here and there, like style="much gibberish" or (span style="much gibberish") (/span). Almost all the time, that is unwelcome. Word will put it in to try to mimic the exact look of a doc in IE -- not what you want.

And Amazon have their own guide which comes recommended:

"Building Your Book for Kindle", and the ebook is free.

Posted by at No comments:
Labels: , , , , ,

Thursday, 1 October 2015

Book Cover Design

Now, I have little to no artistic ability, and less skill and experience in graphic design. So, given that the first hurdle a little-known author faces in a potential reader's mind is the book cover, that's clearly a problem.

My approach, once I realised that I needed a cover at all, was to look for suitable images that I could license to use. I found Dollar Photo Club, and began trawling through the images, using various search terms to ease the search. I was lucky to find something (a model, in a situation) which I felt would work quite well. Then I put a little thought into the font to use for the title, and put something together in the free GIMP (GNU Image Manipulation Program), which many people argue matches and in some areas exceeds the power of Adobe Photoshop. I personally find the user interface diabolical – thank heavens for kindly people on Youtube! So the end result was this, which I thought quite good, considering.

Basically, I just cropped the full image to fit the page, and added the title, author, and image copyright texts.

However, my first rude awakening came at the one day course by the Australian Society for Authors Book Marketing and Publicity, where I was given some frank feedback:

  • It looked amateurish
  • It was too flat, too two-dimensional
  • It didn't really indicate what the story was: it could be about wild party-girls.
  • It was probably good enough for an ebook.

So, I added the tagline for the book onto the cover, and spoke to people with some artistic and design skills, to learn what “too flat” meant. The general consensus was to bring in the sides of the original image (just sacrificing some fog) to give some depth. This would also have the main character look a bit hemmed-in and oppressed, which fitted nicely with the book. Opinions differed about where to place the tagline – centred or off-centre – and I realised I'd need to prepare multiple variants and then show them to people to see if a general preference emerged.

So, after a day of learning more about the GIMP, here is my 2nd version:

I messed up her right boot, and need to fix that, but before I did that I had the opportunity to get some more feedback, this time from the Marrickville Writers Group. Again, I got lots of good feedback, and a definite consensus emerged as to what more needed to be done.

The writers group suggested modifying the model to suggest futuristic stuff, and magic, but that idea, though good in general, didn't fit the story.

Other ideas were to use the title as the focus and move the image into the background, perhaps even use the model just as a silhouette, with the rest of the image used more as a texture. (Note that the images shown here are quick rough sketches and doodles from Lyn and Joe in the Marrickville Writers Group, who kindly let me share their sketches on my blog.)

Wilder ideas were to use a blocky futuristic font with some decoration of the letters to suggest growth or wildness attacking or over-riding the solidity of the font.

The upshot of this was that I realised that my poor skills were quite inadequate to execute these ideas. And the idea of learning how to use the GIMP well enough to do them was almost as daunting.

A couple of people also suggested something which I had been considering myself: getting a professional to work on it. In the meantime, having something concrete and which I was moderately happy with would be a big help in providing a brief to real book cover designers. Options include crowdsourcing (like fiverr) or Goodreads cover specialists (there's a discussion here https://www.goodreads.com/topic/show/2193464-book-covers) or Kindle Groups designers.

Aesthetics aside. But let me leave the huge topic of aesthetics aside and consider what goes into a cover. Perhaps a little list is the best way to do this:

  • Cover image
  • Title
  • Font: for the title, and the font for the rest of the text
  • Author name
  • “Tag-line”
  • Series name and number, if appropriate
  • Spine design
  • Back cover design
  • Back cover blurb – a short blurb, or a longer synopsis?
  • Space for the barcode and ISBN
  • Bio for yourself, and author photo
  • Text and design for “ears” (the inside flaps if there will be a separate wrap-around cover)

I'll try to cover each of those topics briefly, below.

Cover image. This is crucial, as is the title. The cover is what you hope will catch the reader's eye, and interest. It needs to suggest what the book is about, and all the elements need to be harmonious. It's the first big hurdle you need to overcome in your quest to guide people to buying your book.

Title. What can I say about this? If the “elevator pitch” is a 25 word encapsulation of what your book is about, and the tag-line is an eight word hint, then the title is your novel distilled down to its essence, its heart. The approach you take for a title for fiction books is quite different to non-fiction: for the former, you want to rely on connotations and echoes, and for non-fiction you want to highlight what's unique about your book.

Font. The choice of font for the title is extremely important, too: although more so for fiction than non-fiction, I feel. I hadn't thought very much about this for my first attempt: I chose a cursive font because to me it suggested natural-ness (an echo of the “wild”), with a drop shadow so it could be read against the background. But one of the members of the Marrickville Writers Group with some cover design experience (hi, Lyn!) mentioned that drop shadow fonts for a title suggest the Mystery genre to readers (so, I should avoid that). There was general agreement that my choice of font for the title was wrong because it came across as too girly nor did it convey the futuristic angle.

The title font may benefit from being very eye-catching and highly decorative. The font for the rest needs to be more legible. Nor do you want a fruit salad of different fonts. That said, here is a site where you can get fonts for your cover: http://www.fontsquirrel.com/. An extra good thing about that site is that they also tag fonts, so you can search for things like “futuristic”: http://www.fontsquirrel.com/fonts/list/tag/futuristic.

Author name. Obviously you need to put the author's name there. But what name? Consider a pseudonym; consider variants of your name. My family actually suggested to me that “Luke Kendall” doesn't really roll off the tongue, whereas “Luke J. Kendall” is easier to say. And does the middle initial get put down with or without a period? A quick scan confirmed that, yes, the period is in.

“Tag-line”. I'm no expert on this: I bet Google would help you find good articles on how to do this. I'm pretty happy with what I came up with. The function of the tag-line is to help cue the potential reader in to the subject of the book. Since people had pointed out that “Wild Thing” could just as well refer to a wild party girl, adding the tag-line solved that particular problem.

Series name and number. One of my pet hates is not being able to easily find the order of books in a continuing series (Hi, Kim Harrison). Having to resort to Wikipedia and then using a permanent marker to add the number is not something I feel I should have to do. So, since I'm planning a whole series of books, I needed to add that somewhere. Oh, and then what to call the collection: Series, chronicles, report, archives, … in the end, I felt “dossier” best fit the subject matter.

Spine. If you're going to have a printed edition, then you need a design for the spine, and it needs to wrap around and fit with the front and back cover designs. As well, you will need to know how wide the spine will be, so that means you need to know how many pages, and the paper thickness. Fortunately, since I plan to use CreateSpace (https://www.createspace.com/Products/Book/), they make it easy by providing a calculator, once you've chosen the paper type: be aware, that cream and white paper have slightly different thicknesses!

Back cover design. If you have a printed edition, naturally. Have a look at some published books to see what goes here. Also, what goes here will be different if the cover will be loose and separate (this, with wrap-around “ears” where readers will expect to find the blurb, and perhaps the author bio), or if the cover will be more like a paper-back (integral to the book, no inside flaps). Also note that CreateSpace can't print on the inside of the cover, at present. So if you want your bio, it'll need to go on the back cover.

Back cover blurb. This is hurdle #3: if the potential reader likes the cover image and title, there's a good chance that the next thing checked out will be the blurb. So it pays to wordsmith this until it's as near perfect as you can make it. I think a similar effort to what's needed for writing poetry goes into this, since every word counts. Don't go overboard with this: the text will need to be very legible, regardless of the back cover beneath it, so it will need to be reasonably large, and thus reasonably short. Also, don't think that a synopsis is the same as the blurb: write a separate synopsis, don't just add to the blurb. Nor should you give away too much: you'll spoil the pleasure for the reader if you do more than provide them hints as to some of the twists. You certainly should notbe summarising your story. Yes, it's a fine art!

Barcode. Yep, you need to get an ISBN and a barcode for the ISBN, so leave space for them. If a book seller can't catalogue your book, there's no chance they'll add it to their inventory. Book retailers have enough problems: don't make more for them.

Bio. Readers are often interested in knowing a little about the author. Write something that gets across who you are: your personality. You may also want to include a nice photo of yourself.

Ears or flaps. You'll need some text if you plan on a printed book with a dust jacket, since the inside flaps is where readers will expect a blurb, or a longer synopsis if you wish. Have a look and see what other authors do.

Cover design. You have a wide range of options here. What I started with was a source of licensable images. I did some google searching and found Dollar Photoclub which suited my needs nicely. I was careful to read the license terms, to be sure I could use the images for a book cover design and for general promotion of my book, if I paid for licenses for the images (which were very reasonable, I thought). (I'm told you can also find free images, but the difficulty in being sure that they really are free is not worth the trouble, in my opinion.) Dollar Photo club also tags images, so you can search the large set of images by keywords, and then browse through the resulting images that match: that's a real help!

Other options are pre-made book covers: you browse through and buy the one you want, and they remove it so no one else will end up with the same cover design as yours (which is a danger when you rely on stock images). I'm sure there are several of these sites: I had a bit of a look at http://thebookcoverdesigner.com/product-category/premade-book-covers/ and http://www.thecovercollection.com/premadeebook-kindle-covers-fiction. These options are very cheap, and although you could get lucky and find something exactly right for your book, they generally won't look as good as a special design made just for your book.

Kindle Direct Publishing also have their own cover design “tool” where you can add the title etc. as well as an image. If your design skills are good enough, you might be able to get a reasonable design that way.

Another option is crowdsourcing (like fiverr), where you provide a brief for the work you want done and then people will vie for the work. I gather with fiverr, you specify the amount you want to spend, and the “bidders” will work to that. Obviously, if you set your price low, you will get fewer people vying for the work.

If you yourself have good design skills, you can do it yourself: but be aware that there are nuances to book cover design that you will need to learn: different genres have different expected styles, and if you design a cover that doesn't fit that, your book may well be overlooked or disregarded. Even the style of font and font effects matter. It's a specialist art. Here are a couple of articles you may find useful: 14 Tips for Good Kindle Cover Design/ and What Does Your Cover Say About Your Book/ if you want to take that route. Note that the first of those two links is someone who will also design a cover for you.

My own experience. So the upshot of making my own best attempt at a cover and learning a little about the topic was that I realised I should find someone better than myself to create the cover for my book.

Soon after coming to realise this, and primed by my heightened awareness of the subject of cover design, I noticed in passing on Twitter the covers for the series Norma Jean's School of Witchery by @RoseMontague, and thought “Wow, they're good”. I contacted her to ask who designed them and Rose very kindly put me in touch with Mirella Santana of Brazil, on Facebook as https://www.facebook.com/mirellasantana.digitalartist and at http://mirellasantana.deviantart.com/, and I was hooked.

I contacted Mirella and outlined what I wanted, and since she was interested, proceeded to prepare a brief.

Writing a design-brief. I should point out that I don't know the right way to do this; what I provided Mirella was an early blurb for my book, a slightly longer synopsis, my bio, a short background section for the world of the story, my attempts at my own cover (along with a summary of their flaws), the cover details:
  Title:    Wild Thing
  Tag line:    She's not what they planned
  Subtitle:    The Leeth Dossier: vol 1
  Author:    Luke J Kendall
as well as a list of ideas related to incidents in the story that might form a suitable starting point for the cover design, including a list of the key characters and the roles they play. I was able to point Mirella at the model whose photos I'd found, since she was a surprisingly good match to my own mental image of my main character, and there was a good number of possibly suitable images of her available.

After a while, Mirella provided me with some samples; and we went back and forth a little bit via Facebook, discussing them, as well as providing the extra information needed (like the physical dimensions of the printed book, including the number of pages). I made a few suggestions (in the initial image, the position of the dog and the monster suggested the main character might be a werewolf; and might even change into the monster too, rather than being threatened by it. Mirella's solution to that problem was much better than my suggestions, incidentally.

Later, I provided updated text for the back cover. Mirella added the period in “Luke J. Kendall” since I hadn't been aware of that convention; she also highlighted some of the text for the back cover for those readers who just want to skim the synopsis for interesting tidbits, rather than read it all.

Mirella also pointed me at a site where we could transfer large files to one another (https://www.wetransfer.com/), and I simply used Paypal to pay her for all her excellent work.

The whole process was enjoyable and pleasant; I did try hard to be responsive, and tried to answer all her questions promptly. I can certainly recommend Mirella: I think I was very lucky to find her. My situation was complicated by the fact that I was in the middle of working on splitting the book into two, and dreaming up the right “something” that might make the first half a compelling book in itself. At least the title still worked: but pretty much all the rest of the text on the cover had to change.

So what does the cover look like? Well, I had Mirella design two variants: one with and one without the dog. Here they are, side by side, just the front cover parts: (Incidentally, adding the image with the dog took almost two hours: looks like a bug in Blogger. The only way to make the with-dog image to appear at all was to first add it to a Picasa/Google Photos album, and then add it to the blog from there. Go figure!)

OR OR

 

 

 

 

 

 

 

 

 

 

 

So, I think it's appropriate to show you Mirella's design and finish with a poll (thanks to Matt Koble's post about How to Embed a Poll on a Blogger Post), since there is still one question open about the cover: do more people prefer the with-dog version, or the without-dog version? Please vote (unless I've already asked you in person)!

Do you prefer the design with the dog, or without?

And one last thing: Mirella said that if people had questions about the book cover design, she would be willing to answer them. Perhaps we could do them right here on this blog; but if you'd rather contact me to ask Mirella, that's fine, too.

Posted by at 4 comments:
Labels: , , , , , , , ,
Subscribe to: Posts (Atom)