Status of this page: expand| June 14, 2017
eBook publishing might be defined as making content available on an eBook device (sometimes referred to as an e-reader), however, for the purposes of this book, we must be able to broaden our definition to include any screen based device. The reason for this, is that many people will read their eBooks on a smart phone rather than dedicated eReader. More significantly, though eBooks can also be read with a web browser (see GitBook and LeanPub), so eBooks can also be delivered as web sites.
It is common practice amongst traditional print book publishers to orientate their workflow to design and typeset for print with the eBook production coming later in the process.
When an eBook is created it simply consists of a file. As an example, in this book we will create an ePub of the Shakespeare play and the result will be a file named thus:
The name of the file is arbitrary and chosen by the creator. In this case ‘lifeofspeare’ is used as a shortened acronym for ‘The Life of Skakespeare’. Further information about the file and eBook is held within the metadata. We will learn how to add the metadata to the eBook later during the various chapters.
This file could be distributed to anyone by email or simply saving on a USB flash stick or sharing on a cloud service such as Dropbox or GoogleDrive.
The file itself then needs to be added to the user’s device (iPad, Samsung tablet etc). Mechanisms to achieve this are not that simple and may require attaching cables from computers or transferring via special apps (this approach is referred to as ‘sideloading’). Tablet devices are somewhat easier to achieve this transfer, because you can use other apps such as email (emailing yourself from a PC and then grabbing the attachment through the device email app), or cloud storage solutions such as Dropbox. eInk devices (Kobo, Nook etc), do not have access to other apps, and so cables and sideloading is the only option.
The options above are rather unfriendly to your users and are really not a good option unless you plan to give the file away. Some publishers have a system of purchase through a web site and have determined to make life easy for themselves and their customers by delivering to a cloud service such as Dropbox. The publisher O’Reilly uses such a method and they do not use any file protection such as Digital Right Management (DRM).
When we buy our eBooks through our digital accounts, our eBooks belong to us only through the system from where we purchased. This is not always true, but publishers do need to decide if they will put their publications through the vendor specific ecosystems.
Some of these stores are listed below:
The iBookstore is available from within the Apple iBooks app on iOS on your iPad. This is deliberately convenient of course. From your library you go to the ‘Store’ where the latest books are displayed for your pleasure and purchase!
** I need to research how publishers get their books on to these stores. ** Many (maybe all) of these systems use the Adobe Toolkit to display their eBooks—this is the same as is used in the Adobe Digital Editions application for computers.
It is possible through an eCommerce system on your own web site to sell your eBooks. Purchasers will be able to download the eBook file, once they have completed the transaction. If you feel the need to protect the file from further distribution, then you will need to make use of DRM (Digital Rights Management) software. This means holding information about the purchaser and relating this to the downloaded file. Adobe have a licensing server solution called Adobe Content Server although it does not come cheap. EditionGuard is an other option, although this still uses the Adobe solution.
If you research these solutions for yourself, you are very likely to conclude that having DRM is just not worth the hassle. If you are really concerned that your eBook will be ‘copied-on’, then I suggest selling through Apple and/or Amazon. This way, you can ensure that the DRM is handled through the vendor.