Tim C. Taylor's Blog, page 11
October 17, 2012
The Reality War Book1 eBook is now free, except for UK Amazon

Book1: The Slough of Despond
As from today, the eBook version of the first novel in this two-book time travel series is free from Kobo (free) | iTunes (free) | Smashwords (free) |Nook (free) | Sony (free) From Amazon (Kindle) its list price is only 99c or 77p, but amazon.com are currently price matching to be free there too.
So try this adventure series today. Residents of Elstow, Bedford and Bedfordshire should certainly try this book. How many science fiction novels have you read set in Bedfordshire? If you don’t have an eReader device, then that’s not a problem. All the major retailers have free reader apps for PCs, Macs, Apple and Android tablets and Smartphones. Alternatively, get the free copy from Smashwords and read it on the free reading software: Adobe Digital Editions.
The eBook edition of Book 2 is available to buy for all those platforms except for Nook. I’m expecting Barnes & Noble to load it up any day now.
See The Reality War web page for interviews, articles and more.


The Reality War Book1 eBook is now free, except for on Amazon

Book1: The Slough of Despond
As from today, the eBook version of the first novel in this two-book time travel series is free from Kobo (free) | iTunes (free) | Smashwords (free) |Nook (free) | Sony (free) From Amazon (Kindle) it’s only 99c or 77p/
So try this adventure series today. Residents of Elstow, Bedford and Bedfordshire should certainly try this book. How many science fiction novels have you read set in Bedfordshire? If you don’t have an eReader device, then that’s not a problem. All the major retailers have free reader apps for PCs, Macs, Apple and Android tablets and Smartphones. Alternatively, get the free copy from Smashwords and read it on the free reading software: Adobe Digital Editions.
The eBook edition of Book 2 is available to buy for all those platforms except for Nook. I’m expecting Barnes & Noble to load it up any day now.
See The Reality War web page for interviews, articles and more.


October 16, 2012
Success often needs a little time and effort…
I was intrigued by this article from the BBC about a letter from JRR Tolkien to Arthur Ransome. Sales of The Hobbit had been disappointing, it seems, but Ransome had some suggestions for improvements…
http://www.bbc.co.uk/news/entertainment-arts-19965058


October 11, 2012
Win The Reality War in paperback
Anyone who fancies a science fiction adventure series featuring time travel, intelligent reptiles, an enigmatic figure who might have a strong connection with Bedford’s history, and a chase scene set on a North Sea ferry… if anyone’s still there, Goodreads are running a competition to win a set of Reality War paperbacks. Open to US an UK readers and running until October 19th
Good luck!
http://www.goodreads.com/giveaway/show/34580-the-slough-of-despond


Why JK Rowling has my sympathies
Book lovers will have noticed that JK Rowling has just released a new novel, and it is neither a children’s book nor connected with the Harry Potter universe. Casual Vacancy has polarized opinion; it’s a triumph for some, an author overreaching herself for others, and a sizeable minority who choose to leave online reviews complain of the book’s vulgarity. I guess a wide range of opinions was inevitable, though I am pleased for her sake that a large proportion of the more neutral commentators seem to have at least something positive to say about her book.
What attracted my eye were not comments about the story, but about the eBook formatting. For specific combinations of Kindle or Nook reader device and firmware (firmware is the software that tells the device how to display the book) Casual Vacancy was unreadable. You simply could not set a font size to a setting that was practical to read.
There were a lot of angry comments online, initial confusion from Amazon customer support, and the finger of blame pointed at the publishers for clearly not bothering to test the book. (Here’s a summary from The Atlantic) which led to an admission of guilt from Hachette, the book’s publishers, and a fix the following day. (If you buy the book now, you will be fine. If you had the problem, B&N/ Amazon customer support can guide you to the fix).
Should Hachette have done a better job? Absolutely! You might not have heard of them, but you will have read books from their imprints. They are the second largest publisher in the world, with sales last year of over $10billion. You would think they would have done a better job at checking such a key release. I feel sorry for JK Rowling, and for disappointed readers.
And yet, I do have some sympathy for Hachette. Actually — no — not for Hachette but for the individuals who worked on the project, some of whom may well have been asked to collect their belongings and leave the building for the last time. Take my comment that Amazon customer support had no idea what the problem was — well, they should have done! Because the symptoms seen in Casual Vacancy have been seen in hundreds, probably thousands, of other Kindle titles since the spring. I’m sure the individuals on customer support were trying their best; they didn’t know what the problem was, but Amazon as a company did.
Letting Hachette off the hook sounds ridiculous, but I’m going to explain why I feel some sympathy in this article by letting you in on the wacky world of building eBooks. Normally I would say: do a shabby job and you deserve to be out on your ear. But I reckon that building eBooks is not always as easy as you might think, and almost certainly not as easy as it will be in a few years’ time.
I had similar comments directed at a book I once built for the Nook. 1-star reviews because the book wouldn’t load up at all. As soon as I heard of this I looked into the problem. It didn’t take long to find that hundreds of people had the same problem and they were having problems with a seemingly random selection of books from a wide range of publishers. In fact, what the victims had in common was not the book title, but their Nook device itself. The cause was a faulty software update that Barnes & Noble had rolled out that didn’t work on some older Nook devices. It made no difference which books you had in your library, but if you were unlucky some would fail to load. Of course, as a reader seeing some books load and some not, I would naturally blame the publisher. People did! But there was nothing we could have done to build the books in a way that would have been immune from this problem. By the time I was aware of the issue, Barnes & Noble had already rolled out a fix to their faulty software.
As for tiny fonts on the Kindle, I have certainly seen something that sounds suspiciously similar.
When you write the software for an eBook you have many ways to specify how big something should be, whether a margin or a font size. In fact, it is a rag-tag mess that represents the evolution of HTML and CSS, the languages used in eBook code. You could choose to specify font size as small, medium or large, as a % of the parent font size, as smaller or larger than the parent font. You could decline to give any information about font sizes and hope you inherit a sensible default. Or you could use a unit called an ‘em’, which in theory should be the same as using %, but in practice, isn’t. You could use ‘absolute’ units such as cm, pixels or… the unit you are probably familiar with from word processors… points.
If you’re having difficulty getting to sleep, try this as a typical online discussion about setting font sizes. It’s talking about web pages, but they use the same html/ css software language as eBooks.
What I find interesting is to see there are over two-hundred comments for an article written in 2008. It was written 4 years ago, and the last comment was posted just 4 days ago as I write this. And if you look closely, the answers are changing as the web browsers change. When the article was written, pixels were considered an absolute unit; now many web browsers will scale items sized in pixels. With the Kindle 3, 4, 5, DX and Fire, points are scalable units too. Or they were.
And so it is with eBooks. You can get a book on CSS and read up what all these various size units mean in theory, but that means very little in practice. What the reader actually sees on the Kindle screen is up to the Kindle software and your book’s code getting in a huddle with your user settings, and hashing out a compromise about which of the device’s font sizes it will choose to display.
I bought my first Kindle device 18 months ago. Until last Friday, it had seven font sizes. That’s it. There was no point in specifying 0.875ems or some such — that precision is an illusion — it simply mapped onto fonts 1 through 7. And carefully setting margins in ems didn’t work either. Your alignment and spacing would look wonderful in your web designer or InDesign, but the Kindle device would round everything up to the nearest whole number of ems.
Then on Friday, my Kindle upgraded itself, from software version 3.3 to 3.4 If I had bought Casual Vacancy on Thursday, it would have read fine on my device. If I had bought it on Friday, it would have been unreadable because the software update meant my Kindle now displayed Kindle books in a different way, and a way that the Hachette eBook coders hadn’t accounted for.
I myself had a problem with a book that worked fine when I built it, but between building and publication there had been an update to the Kindle 4 and Kindle Touch devices that rendered it unreadable, and with what sounds like exactly the same problem as Casual Vacancy.
A lot of people are saying Hachette didn’t test the book. I think a more likely explanation is that they didn’t re-test the book. I worked for 20 years at a software organisation delivering software that was expected to be maintained for many years. We would always take a lot of care in thinking about which configurations we would test against. In fact, our customers would expect us to tell them exactly this sort of information before we would issue a release. If a new version of Oracle or SQL Server, or Windows had come out, our customers would expect us to say whether we supported that new version.
My guess is that this book was tested by Hachette but several months ago, and was not re-tested against new Kindle software versions as they came out. When we made a software release at my old company I would encourage everyone in the organization to spend a morning installing and running the new release. I called it Bash Testing. With all the secrecy about Casual Vacancy, I imagine the exact opposite happened, that the book was kept securely locked away — during which time the book quietly stopped working.
Should the Hachette coders have anticipated this problem? Actually, yes, because it’s a problem that’s been known about since the spring. The question of culpability can get quite heated online, but it’s a bit of eye-opener if you don’t know anything about how eBooks get made. It comes down to the question of how to set font sizes in the code.
For small and self-publishers, Amazon suggest four main ways of making Kindle books, two of them assume you will set font sizes using points, and two of them made no assumptions about how you would specify font size (although Amazon changed its guidance this year to suggest those two solutions should use %’s as the unit). To get the problem you need to specify font sizes in points, but it also depends on which tool you used to build your book, which Kindle software version is reading the book, and possibly which phase the moon is in (okay, I still don’t know precisely which combination brings up this problem). The most compelling guess that I’ve read on the internet is that someone at Amazon who wrote the Kindle software update got pixels and points confused. You specify 12 point text but the Kindle displays it 12 pixels high. That’s unreadable.
Even though Amazon has always recommended that eBook designers shouldn’t try to set font size for the body text (because it might override the reader’s settings) they have always encouraged you to do so with headings and other text. Units such as ems or %’s are theoretically scalable, so it’s a fair argument that eBook designers should always have used these measures because they were always more likely to be robust, even though Amazon’s own coding samples used points to set sizes. So I don’t believe this change was deliberate from Amazon, because there was a point earlier this year when one day you could build a book that followed Amazon’s coding guidelines to the letter and it would work fine, and the very next day that same book would not work for readers who had received the new Kindle software update.
Whether you regard that as a bug or not, Amazon have certainly known since the spring that hundreds, possibly thousands of Kindle titles have fallen foul of this problem. I know less about the Nook problem, but it may well be a repeat of the same story over at Amazon/ Kindle.
None of this is to excuse publishers who put out books that do not work. And that includes myself.
But I feel sorry for JK Rowling. And I do feel a little sympathy for the Hachette people who probably built the book months ago, tested it, and thought they had done a good job. I can almost hear them say: “But it worked on my machine!” I used to hear that a lot from coders in the early 90s, but it doesn’t cut it in a professional software team these days. Hachette Livre — or whoever you use to make your books — welcome to the real world of software development.
Help! How do I fix my book?
I know some Kindle self-publishers read this blog, so if you have a touch of the Casual Vacancies with one of your own books, here’s the fix for Kindle.
I’ll assume you’ve got the html file that you saved from Word (using filtered html file type) AND a text editor. On a Windows PC this would be Notepad. Don’t use Word or another word processor to edit the html
Start Notepad (or your choice of text editor) and open the html file for your book.
At the top of the file you should see a `Styles’ section. You should find one entry to correspond to each style present in your Word document. The styles called `h1′ and `h2′ etc. correspond to the heading1, heading2 styles, and there might be a style called `p’, which is very important because it gives settings for the default paragraph style. This style section is your CSS.
For this problem, you want to take out anything that says something like
Font-size:12pt;
For the `p’ paragraph style and your `normal’ and `body’ styles you don’t want ANYTHING for font-size. Simply delete the font-size line (but make sure the style definition still ends with a `}’ character.
For heading styles you DO want to set the font size, but need a different way of stating it. Instead of something like `font-size:16pt;’ change to a % value such as `font-size:160%’. The % gives the multiple of the default font size, and the default font size is whatever the users set on their Kindle.
That might be all you need to do. But it is also possible that you have set some styling directly in the main body of your html file. Do a search for the text ‘font-size’ If you see that anywhere, change the pt size to % (although you will probably find this a lot in the code for page breaks — I’m not convinced you need to change code for page breaks).
HOW TO TEST
As a simple test, once you’ve saved the html file from Notepad, you can open the html file in your internet browser. That’s just a quick first look, though. Always download the .mobi file from the Amazon KDP edit book details screen once you’ve uploaded the book. This problem currently shows itself on Kindle software versions 3.4, 4.1, and 5.1 The Kindle Fire works fine.
INDENTS
If you get the hang of simple html style editing, you might want to handle paragraph indents too. If you want paragraphs to not have a first-line indent, go to the corresponding style entry in the html file and add
text-indent:0;
AN EASIER WAY?
If coding is not your thing, you could use a third-party tool. Calibre is one. You could convert from html to mobi and upload the result. This might fix your problem, but it might not. It may be worth a try.
Lots of people use Calibre, including Smashwords, to make Kindle books, although the results don’t match Amazon’s coding guidelines, and Amazon sometimes reject books built through Calibre (probably because the Calibre developers have had to guess how the Kindle header is supposed to work and not guessed correctly. If this happens to you, re-covert through Calibre but this time send the output to a debug folder. Run Kindlegen over the contents of the ‘processed’ folder and Amazon will accept it).


Kindle 3.4 firmware upgrade … and using Calibre to build eBooks
If you’ve got a Kindle 3 (now called Kindle Keyboard) then there’s a fair chance that over the past few weeks, your Kindle device took it upon itself to download a software update and a new book from Amazon to tell you how wonderful it is… it being Kindle firmware 3.4 and its support for the ‘new’ KF8 file format.
The timing could have been interesting for me. If I had bought the Kindle version of JK Rowling’s new book, Casual Vacancy, when it was first launched, then my Kindle would have displayed it perfectly. If I had bought the book two days later — following my firmware update — it would have been unreadable. You might have read about the eBook disaster that befell the Kindle and Nook launch of Casual Vacancy — the words were unreadably small (the publishers have issued a fixed version of the book, incidentally) on certain device/ firmware combinations. Such is the sometimes tricky world of eBook coding — or perhaps I should say eBook design as there are plenty of self-publishing authors who look upon eBook ‘coders’ with deep suspicion because they see no need for any coding at all, being perfectly happy to do all their work inside their word processor.
Is there really any need to get your hands dirty with html and xml coding in order to produce good eBooks, or is this a conspiracy designed to overcomplicate and obfuscate in order to justify fat fees? I’ve lost count of the number of eBooks I’ve built, but when you add them up and include all the various formats, I must be heading toward 200 books. So I feel somewhat qualified to give an opinion. I’ve a skewed view of this because I know I get the complicated books where an author has had a go, realized that what he or she wants to do isn’t as easy as they thought, and hand on to me. Certainly some of the layouts I’m asked to produce can only be built by writing code. But in many cases the work I do in html, css, or xml is the professional polish and future proofing. Most of the eBook layout work I do is inside Microsoft Word. That’s an interesting topic, but one I’ll concentrate on another day.
Today I wanted to share a thought on Calibre. This is a tool designed to help you keep track of your electronic media — newsfeeds as well as eBooks — and organise both your library and your reading devices. It’s a great tool… but for that purpose. It was never designed for publishers to build eBooks, but that’s what a lot of people use it for.
It’s tempting to use it to shortcut eBook development, something crying out to have better development toolsets. I know, I’ve been tempted myself. In retrospect I would have been better off writing my own tools to automate common coding issues such as generating the book navigation.
One route I’ve been tempted by looks like this:
Do as much styling, tidying, and screening out naughty things such as tabs while still in Word or Open Office.
Save out to html
Import into Calibre and convert to ePUB format, taking care to turn off all the things that break Amazon Kindle coding standards, such as font scaling and setting line height.
Open up the epub file in Sigil and hand code away coding problems, such as spurious blank paragraphs that have been inserted to simulate paragraph spacing for headers, fix anchor tags in the wrong place, and reinsert images. I also take a good look at the CSS and recode to match the latest Amazon guidance.
Run KindleGen over the file to build the Kindle file.
In actual fact, that does work… but only for some Kindle firmware. Kindle 3.4 firmware probably does. Kindle 3.3 definitely doesn’t. At least one of the problems lies with elements with more than one class.
You what?
Here’s an example from the ePUB code of a forthcoming thriller called The Saxon Network that’s been through this route:
‘Disgraced intelligence officer wanted for murder in Italy on the kill again in World Service newsroom brawl.’
That paragraph tag has a class attribute. That’s fine… they all have that. But the ePub code gives the paragraph three classes: FirstLine, Calibre7, and SGC-2.
The problem is that Kindle firmware 3.3 only considers the first class, it always ignores subsequent classes. Kindle 3.4 will reflect all three classes. Well, that’s great, I thought; with the advent of Kindle 3.4, the Kindle devices can now understand something closer to ePUB code… I can use the Calibre-ePUB-Sigil route.
Alas — when I looked closer, some of the reader apps, such as Reader for iPad, still don’t support elements with multiple classes. The route is still not safe, at least not without careful testing.
If you’re brave and competent enough, you might want to use this route anyway. Look for examples in the code of multiple classes and recode them. Often you can spot this from the CSS. Take the class ‘Calibre7’ in the example. In the source code fed into Calibre, the paragraph was in italics, coded directly by using an tag rather than CSS. Calibre decided it would be neater to have the italics in CSS and so created a class (Calibre7) that looks like this:
.calibre7 {
font-style: italic
}
While I can see some good arguments for coding the paragraph this way, there remains a compelling reason why we mustn’t do this in the Kindle code: it simply doesn’t work, at least not for some Kindle device/ firmware combinations.
This fix in this case was simple. Locate every use of Calibre7 and replace with tags.
There will come a time when the number of Kindle devices and reader apps that do not support multiple classes will have dwindled to a small enough number that you might consider it too small a group to code for. Perhaps, but that time is not yet now.
(By the way, if you do use Calibre to build eBooks that you go on to sell, please donate to the Calibre project. Personally I pay either $2.50 or $5 per book depending on how much use I’ve made of Calibre. If I start using Sigil, I’ll do the same with them).
In building eBooks, I’m reminded somewhat of early software development with Microsoft Windows. My first Windows coding was for a drugs company using Windows SDK 2.1 By today’s standards it was ridiculously complicated. A ‘hello world’ program was several hundred lines of code and terribly fragile. So much of that coding environment felt unnecessarily complicated. Perhaps Windows needed to be complex, but to code Windows applications shouldn’t be. Within a few years, I was helping to roll out new development environments such as Borland Delphi, which made it possibly to write Windows applications much more quickly and deliver something more robust.
Right now we have a range of tools that don’t quite do what I want: Calibre, Sigil, Jutoh, Microsoft Word (!), InDesign. I think InDesign is probably closest, but at £450 for a licence, the price is steep for something for which the Kindle plugin is still in beta and people still report is buggy. I’m sure within five years, this situation will be a distant memory in the minds of veterans, just as it was 20 years ago with early Windows application development.
I look forward to the time when I’ll look at the newer generation of eBook designers and tell them they don’t realise how much easier they have it, just like I did with Delphi developers in the mid-90s. Until then, there is a lot to be said for those who cut away as much complexity as possible and simply hand Amazon Microsoft their Word documents to be automatically converted into Kindle books.


October 4, 2012
I'm very pleased to announce that I'll be giving author interviews...
Click “Author Interview” aboveto get an interview form!
to all the fine authors I’ve had the privilege to meet online. If all goes right, there will be one interview per day for as long as I get the interview forms back.
If you are interested in being interviewed, feel free to contact me here, and I’ll be more than happy to send you an interview form. Come one come all !
Tom does a great blog and it's coming popular too. Writers wanting to be interviewed should get in touch.
October 3, 2012
Event writeup: FantasyCon 2012
Reblogged from Greyhart Press:






Earlier this year, Greyhart Press ceased to be an eBook-only publisher (see here for the slightly naughty announcement). With about a dozen paperback books available or planned to be ready in time, the FantasyCon convention in September seemed a good place to start showing off our books, as well as meeting interesting people, salivating at the sight of all the books available there, and generally having a good time.
September 25, 2012
The Reality War. Book2 out in paperback. Book1 free!

Book1: The Slough of Despond
My mini-time travel adventure series: The Reality War is finally out in paperback. I’ve also cut the exclusivity deal with Amazon so both novels are coming out in eBook form for iPad, iPhone, Kobo, and Nook (though not yet at the Nook Store). To encourage you to try, the first book is free for the new eBook formats, though at 99c/ 77p it’s almost free for Kindle too.
The Reality War is set in Bedfordshire and loosely inspired by John Bunyan’s Pilgrim’s Progress. In fact, as you finish book2 you will realise that… well, that would be giving away spoilers. It’s got time travel, aliens, the future and the distant past. Aliens and dinosaur descendants show off their cuisine, and there’s a touch of romance for a variety of species. As well as Elstow Abbey, Bedford, and Bromham, it features such exotic locations as a North Sea Ferry, The White Hart at Beverley, Brussels, and Elstow during the late Jurassic.

Book2: The City of Destruction
The two novels total over 200,000 words, so if you fancy getting stuck into a satisfying read, why not get started today?
People often ask me to compare my novels with other authors. I’d say that if you like reading Stephen Baxter or Peter F. Hamilton, then you should enjoy The Reality War. On the other hand, while there is definitely a war between realities, it is not something I would describe as military science fiction.
For interviews, articles, extracts, and how to buy, follow this link…
I’ll be at FantasyCon this coming weekend for a couple of Greyhart Press book launches. I wasn’t intending to bring any Reality War paperbacks with me, but if anyone wants to see a copy, let me know.


September 5, 2012
The Reality War Book 2 — coming soon in paperback
The artwork has just come through. I think Andy Bigwood’s done an excellent job. Expect a print edition to be published in the next few weeks.
If anyone wants a review copy, do get in touch, although you do need to read the first book to get the most from book2 .
There’s more about The Reality War here, with links to interviews and articles about the connection to Bedford, Elstow and John Bunyan.

