More on ePub Author
In the few days since I suggested it there has been a lot of interest in pursuing the initiative. I’ve had contacts from a few companies looking to invest money, expertise, or people, and I’ve heard from a great many people who would love to see just such an application in the wild.
On Goals
I’ve been thinking more about what the aims and output should be. I see a few primary goals:
- ePub3-Compatible HTML Renderer: Extend the WebKit platform with concrete support for the special CSS selectors defined by ePub3, as well as some API-level management of optional feature handling (e.g. for epub:switch and epub:case) and triggers.
- ePub3 Container API: A clean API for collating data in an ePub3 container. This API would know how to handle optional/alternative content and the generation of index, bibliography, and glossary information. It would also allow for the specification of metadata extensions and extended/customized content data types.
- An ePub3 Generator: This would be a user-facing application with support for building valid ePub3 files. It would handle both the correct management of different levels of features and compatibility, and the creation of ePub3-valid HTML5 and CSS content documents.
Other priorities of the above projects would include proper handling of right-to-left and top-to-bottom languages, which currently exhibit some compatibility issues between different CSS properties in the current WebKit builds.
The first two parts would be open-source projects, available to all. The third would presumably have a relatively basic form available as an open-source reference implementation, while vendors could implement their own high-level applications upon the same base. For example, an application similar to iBooks Author could be built on top of the APIs described above.
The whole thing could be dual-licensed under both the GPL and a commercial license, allowing for monetization of the core assets. For example, a vendor with a specific customized feature set might acquire a commercial license to the rendering and generation libraries in order to add customizations particular to their platform.
On Organization
In terms of the expected structure, I imagine a governing body/working group defining the expected output, but only in the longer term. The first and foremost priority would be to develop at least the generator in the short term, with the aim of producing a solid 0.x release to serve as the basis for an official API specification and later 1.0 release.
As regards the group setup, there would obviously be a number of developers putting together the code. These will primarily be folks working for the various interested parties, such as eReader software vendors and eBook distributors. Additionally, we would likely have some means for interested parties to make monetary donations to the effort; this would likely be similar to the rewards system used by Kickstarter, although for various reasons Kickstarter itself is likely infeasible unless some closer-term goals would merit that approach.
On Investment
I’m hoping that a number of publishers and eBook firms will step forward to invest in this effort. The accepted input would most likely be split into different levels based on each donor’s needs from the project. Publishers might donate smaller amounts in exchange for volume licenses to high-quality end-user toolsets provided by vendor donors. The vendors, in exchange for a larger input, would gain commercial source code licenses to develop custom ePub3 generator applications for their individual ePub3 platforms.
This is not to say that we will provide our ePub3 toolkit to form the basis of a non-standard eBook format similar to that utilized by iBooks Author. However, the market thrives on competition, so we do want to let individual vendors compete on the specifications and abilities of their reader platforms; we simply require that they differentiate themselves and their content in a well-defined manner, such that their content can gracefully degrade in other eReaders. Additionally, vendors’ individual directions can better inform any future updates to the ePub standard itself.
Specifically: All output should successfully validate as ePub3 according to the published specification. Any vendor-specific features should be clearly and legally marked as such, and should provide standard-format fallbacks where applicable.
In Closing
I believe that it is an important part of any data format standards process that a toolchain be produced which provides for the users of that format. In this case, I think it is important that ePub3 not only be defined as a standard laid out in copious amounts of hyperlinked text, but also in terms of a demonstration of its implementation. We have seen, in iBooks Author, what happens when one interested party decides to build on top of their own toolkit rather than adopt the new standards. If reference ePub3 implementations had been available in parallel with the definition and ratification of the standard, there might be a significantly different landscape in eBook publishing today.
Let’s set ourselves the aim of providing everyone with a single proven foundation upon which to build; we can then see competition in the market thrive on added-value features rather than who implements which parts of a single well-known specification the best.
