Blog

Low-budget eBook Development Tips

Posted on

eBook creation is complicated, but many publishers and authors have pretty small budgets set aside for their eBook development projects. While we always recommend that you plan your eBook development as part of the larger book creation budget, that is sometimes still not enough to pay for high-quality eBook creation.

If you are stuck in this situation and you have to figure out how to make do with a smaller eBook budget, here are some tips to ensure your eBooks do not suffer.

1. Don’t DIY. The first reaction many people have in these situations is to say “I’ll just do the eBook development myself.” That inevitably leads to many, many hours messing with “automatic” formatting tools, trying to understand techno-speak in the eBook format specifications, and banging your head against the wall every 10 minutes. Your time is valuable, too, so be sure you are taking that value into account when you make your eBook development plans. The same is true of the poor designer you task with this job. If he/she needs to spend 10 hours on an eBook project then you are probably better off sending it to a professional.

2. Choose developers wisely. If you must go to another eBook development company to have your work done (we’ll try not to be sad), be sure to pick someone who has a solid reputation and is available to assist you if you need help. Also, look at their terms of service and understand what they will fix if something is wrong with the files you receive.

3. Quality Assurance. Regardless of who does your eBook development, you know your content better than anyone else. Plan in advance to spend at least a few hours looking through the eBook files on different devices and making sure that the conversion was done properly. You will need to educate yourself on how to do this well, but it is worth the effort.

4. Get professional diagnostics. If you are concerned that the eBook files you paid for are not good, or if you are getting errors from ePubCheck or retailers that you just can’t figure out, consider having a professional eBook developer perform a diagnostic check on your ePub file.

Update 8/6/14: In addition to all of these points, you should always test your files in FlightDeck, our EPUB quality assurance testing tool. You’ll get reports about Validation, Best Practices, and Retailer Support, and more.

Those are just some of the things you can do to make sure your eBook files succeed, even on a small budget.


Why eBook Conversion is Complicated

Posted on

red-buttonIt is still surprising to many people that eBook development is a complicated process. The increase in the number of eBook creation tools over the last 3 years has led to many claims that eBook development is as easy (or should be as easy) as pressing a button.

Despite these claims, nothing could be further from the truth. Yes, there are many tools that can create eBook files, and sometimes these tools can do a decent job, especially for certain types of eBooks. However, when developing eBook files, there is a direct correlation between the amount of human interaction with the code and the quality of the final product.

So, why is this the case? What makes eBook development so complicated?

1. Formats. While many people will say that the ePub and Kindle formats are the same thing, there are still some differences between the two formats. The best practice is to create each format independently, not just auto-convert an ePub into the Kindle format with the KindleGen tool. While that does add time to the development of the eBook, it also increases the quality of the reader experience.

2. Reading Systems. If you look at any of the major eBook retailers you will see that they allow consumers to read eBooks on a variety of devices. For example, Amazon has the basic Kindle, Paperwhite, Fire, Fire HD, and Fire HDX, as well as apps for PC, Mac, Android, iOS, Windows Phone, and Blackberry. While retailers do try to create a seamless reading experience across devices, that is not always possible. The best eBook files will be designed to take the differences and quirks of each eBook device into consideration and attempt to be compatible with all of the reading systems that each retailer supports.

3. Display Engines. On a deeper technical level, every reading system, whether it is a device or an app, uses a display engine to translate the HTML code in the eBook file and display it on the screen. The most common display engines are Webkit and Adobe’s RMSDK, but there are also many variants of Webkit being used, as well as hacks and overrides imposed by each reading system. These display engines do not all work the same way, and you will regularly see both major and minor differences in how eBook content looks on devices that supposedly use the same display engine.

4. And more… Those major hurtles are not the only problem areas for eBook development. There are also the issues that come with fonts, images, tables, lists, and other more complex formatting, as well as enhancements and additional features that an author or publisher might want to include.

In all, designing an eBook is more difficult than just laying out the content in InDesign or Word, especially if you are looking for a consistent design across multiple devices and retailers. Its not going to get easier, either. The difficulties of eBook creation will actually increase with the coming support for ePub3; built-in accessibility, more focus on semantic markup and semantic inflection, better support for enhancements, and other new functionality will add both time and complexity to the eBook development process.

eBook quality matters, and customers will notice when an eBook is not designed well. It is always best to spend the extra time and energy up front to make a better eBook file than to fix an inferior product after your customers complain.


The Incrementor

Posted on

We use many open source tools in our day-to-day operations here at eBook Architects; tools like Gimp, Inkscape, Perl, and Python form integral parts of our process and allow us to keep our costs down. To say thanks, eBook Architects has been looking for ways to give back to the open source community, such as assisting in the launch of the #ePrdctn Wiki and by maintaining and spreading great tools like epub-applescripts and kindlegen-drop-app. We hope that these tools and resources are as useful in your eBook development as they are in ours.

The foundation of any good coding operation is the code editor you use. We recently switched to a code editor called Sublime Text 2, a cross-platform program with a dedicated developer, a consistent upgrade schedule, a large community of other users, and an impressively flexible and adjustable interface and feature set. There are a few things that our old editor allowed us to do that Sublime does not  have built-in, but we were able to code replacement functions in Sublime, keeping the developer learning curve during our switch-over down to a bare minimum.

Today we are releasing one of those new features, a  Sublime Text 2 plugin called The Incrementor, into the open source world! This little tool allows you to do common tasks like re-numbering the PlayOrder values in an NCX file quickly and easily. To download or learn more about The Incrementor visit our Github page.

Major kudos go to the coding team here at eBook Architects (TobyChris, and AJ) for their hard work on this Sublime switch over and the Incrementor plugin.


KindleGen 2.5 update

Posted on

Sorry for the long hiatus… Things are really busy here at eBA!

Just wanted to give my thoughts on the updates released in KindleGen 2.5 today. The release notes include more items, but these are the ones that are most important to me:

Improved transparent PNG conversion: Transparent PNG images (now converted to JPEG) will use white background. This originally used black background during conversion causing degraded reading experience.
While not an update to support transparent PNG, this is definitely an improvement from a development standpoint. Now at least we don’t have to create separate JPGs or flatten our PNGs when building Kindle files.

Resolved indentation issues in Mobi7 related to bullets and numbered lists. This was due to usage of “margin-left” CSS property with bullets and numbered lists. In Mobi7, the margin-left property is being ignored for bullets and numbered lists. The margin-left CSS property will continue to be preserved in KF8.
This has been a big issue for us when developing non-fiction Kindle files. Hopefully B&N follows suit and updates their system to allow lists with 10 or more elements…

CSS property display: none no longer induces an additional space in Mobi7 for inline tags.
Peter over at Extraordinary Commons should be even happy about this than I am.

Resolved conversion failure when dc:Language tag in OPF has attributes (ex: id attribute).
This has been annoying Toby for a while. We include IDs in all of our metadata attributes for ePub and Kindle OPF files.

Overall, this is a nice maintenance update. It is always great to see Amazon (and anyone else!) actively working on support for features and bugs that developers need. Keep on sending them suggestions!


Backwards Compatible Poetry for KF8/Mobi

Posted on

One of the most enjoyable, and at times most frustrating, things about eBook development is learning new systems and formats when they are released. The new Kindle Format 8 (KF8) comes with some great changes to the design capabilities on the Kindle platform, but one of the main challenges in using it is creating Kindle files that will degrade gracefully to the older Kindle devices that do not have support for KF8.

A prime example of formatting that needs backwards compatibility is poetry. In 2008 I developed the now-standard approach of using Mobipocket’s width attribute combined with specific values and non-breaking spaces to make poetry work well in Kindle devices. I covered that in detail in my book, Kindle Formatting: The Complete Guide.

In KF8, the old width attribute is no longer valid, so using this code for backwards compatibility is not possible. In the early beta versions of the KindleGen 2 tool for KF8, there was no way to make the hanging indents work properly in Mobi while still making a valid KF8 file, so I complained to Amazon about the need for a CSS-driven option using media queries. They came through with a small change to the final release version of KindleGen that allows the use of negative values in the text-indent CSS property.

So, here is a new way to create valid code in your KF8 files that will degrade gracefully for older Mobi-only devices.

The HTML is actually pretty simple. The class name designates a paragraph’s level of indentation. The non-breaking spaces are placed inside span tags that can be hidden in KF8.

1
2
3
4
5
6
<p class="poem1">Poem1. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
<p class="poem2"><span class="hide">&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;</span>Poem2. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
<p class="poem3"><span class="hide">&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;</span>Poem3. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
<p class="poem4"><span class="hide">&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;</span>Poem4. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
<p class="poem5"><span class="hide">&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;</span>Poem5. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>
<p class="poem6"><span class="hide">&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;&#xa0;</span>Poem6. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.</p>

The CSS starts off with the use of media queries. One section of the CSS is defining the styles for Mobipocket-only devices, and the other is defining the styles for other devices (those that support KF8 or another future format).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
@media amzn-mobi {
p.poem1 {
text-align: left;
text-indent: -30px;
}
p.poem2 {
text-align: left;
text-indent: -60px;
}
p.poem3 {
text-align: left;
text-indent: -90px;
}
p.poem4 {
text-align: left;
text-indent: -120px;
}
p.poem5 {
text-align: left;
text-indent: -150px;
}
p.poem6 {
text-align: left;
text-indent: -180px;
}
}

@media not amzn-mobi {
p {
margin-top: 0;
margin-bottom: 0;
}
.hide {display: none;}
p.poem1 {
text-align: left;
text-indent: -30px;
margin-left: 30px;
}
p.poem2 {
text-align: left;
text-indent: -30px;
margin-left: 60px;
}
p.poem3 {
text-align: left;
text-indent: -30px;
margin-left: 90px;
}
p.poem4 {
text-align: left;
text-indent: -30px;
margin-left: 120px;
}
p.poem5 {
text-align: left;
text-indent: -30px;
margin-left: 150px;
}
p.poem6 {
text-align: left;
text-indent: -30px;
margin-left: 180px;
}}

The Mobi-only CSS uses the negative text-indent to emulate the width attribute, and the KF8 CSS hides the non-breaking spaces and uses the standard CSS approach to hanging indents (negative text-indent, positive margin-left).

That’s it! Come back later for more posts on KF8 development and backwards compatibility.