Ebooks and their making
Mar. 29th, 2014 04:27 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
blatherskiteI've had three fantasy novels and a collection of short stories published for some time now. I'm very pleased with them, but one thing I haven't had time to do was convert them into a form (EPUB) that's easily usable on an iPad or equivalent device. You can read them for free online, but if you want to take them with you, you have to do it as HTML for now.
I'm currently working with a colleague to see if I can afford to pay her to produce EPUB versions. I can easily generate EPUB from InDesign, which is where the print versions of the books live, but the output has a few problems. Apparently, simple notions like automatically breaking chapters into chapters and automatically linking the TOC to these chapters via hyperlinks is too tough for the whiz kids at Adobe. These problems are not insoluble, but solving them would take time I don't have. Sometimes it's better to just throw money at a problem when time is more valuable than money. Stay tuned; if this goes ahead, I'll announce the results here.
In discussing the issue with a colleague who's a non-self-published published novelist, I got to considering the merits of avoiding EPUB. Frankly, EPUB is so primitive and has so many limitations right now that I got interested in looking for alternatives. And the answer was right in front of me the whole time: HTML or one of its descendents. Given that most reading devices now have a Web browser built in, that's no longer the issue it might have been as recently as a year ago.
The overwhelming advantage of HTML is that it's a mature technology that provides excellent control over every aspect of the publication my readers and I would want to control:
I'm long overdue to update my book on onscreen editing, and I'm seriously thinking about producing it as HTML. Will start looking into this seriously in May, when we're back from vacation.
I'm currently working with a colleague to see if I can afford to pay her to produce EPUB versions. I can easily generate EPUB from InDesign, which is where the print versions of the books live, but the output has a few problems. Apparently, simple notions like automatically breaking chapters into chapters and automatically linking the TOC to these chapters via hyperlinks is too tough for the whiz kids at Adobe. These problems are not insoluble, but solving them would take time I don't have. Sometimes it's better to just throw money at a problem when time is more valuable than money. Stay tuned; if this goes ahead, I'll announce the results here.
In discussing the issue with a colleague who's a non-self-published published novelist, I got to considering the merits of avoiding EPUB. Frankly, EPUB is so primitive and has so many limitations right now that I got interested in looking for alternatives. And the answer was right in front of me the whole time: HTML or one of its descendents. Given that most reading devices now have a Web browser built in, that's no longer the issue it might have been as recently as a year ago.
The overwhelming advantage of HTML is that it's a mature technology that provides excellent control over every aspect of the publication my readers and I would want to control:
- The text is reflowable, so it will adapt to any screen size, and can be zoomed/magnified to whatever level the reader might want.
- You can use CSS to specify the typography, and if the reading device doesn't have the specified fonts installed, it will substitute reasonable approximations.
- On most reader devices, you can install any of several Web browsers until you find the one that suits you rather than being forced to rely on the default browser that ships with the device.
- Navigation within the book via hyperlinks is easy; I already maintain my Web site in Dreamweaver, so it's easy to simply bundle the existing files into a distribution package. At least I think it would be... need to test this. But authoring the files is easy, and that's the important point from a production perspective.
- You can even index the book using a product such as HTML Indexer, which isn't necessary for fiction, but is essential for nonfiction. (What about search tools, you ask? I spit on search tools. They're dead stupid and can't understand context, and are essentially useless for large or complex books.)
- HTML is a fairly "light" format, which means it doesn't take up much space and doesn't take much processing power to display.
I'm long overdue to update my book on onscreen editing, and I'm seriously thinking about producing it as HTML. Will start looking into this seriously in May, when we're back from vacation.