Ebook Formating Tool Wishlist

[aapezzuto]

I have been approached by a friend who is soon to graduate with a CS degree to outline him a reasonable 200-500 hour project. What we have come up with is an ebook formating program, written in C++, using QT, and thinking in epub. Its main goal is to be able to replace book designer as a more plug-in friendly opensource project. So as we are building the project outline and specification, and coming up with use cases, what would the community like to see in such a tool?

I am well aware of the talent in both programing and formating we have here, so I am excited to see what we come up with.

[kovidgoyal]

Consider doing it in python rather than C++, much faster lead times and much easier long term maintenance.

[JSWolf]

I'm all for another eBook design program. Especially one that handles all the features of the various formats.

[Gudy]

Hmm, just a thought, but epub is essentially xhtml, right? Maybe I'm influenced by how BD does things, but I think that having the internal format represent the semantic structure of a book would be important, and I don't think xhtml covers the semantic space adequately. Or are there ways to denote poems, epigraphs, citations, etc. semantically in xhtml? If not, the internal format should probably be closer to something like FB2, except perhaps richer.

Both file input and output should be done via format-specific plug-ins, so it is possible to add new formats and change existing ones without having to change the whole application.

Make it cross-platform. If C++/QT is absolutely your thing, knock yourself out, but like kovidgoyal, I suggest taking a look at Python/QT instead.

[HarryT]

When you say "replace Book Designer", do you mean a GUI tool which will, like BD, allow numerous formats (text, HTML, RTF, PalmDoc, etc) to be input, and the creation of numerous output formats (Sony LRF, MobiPocket, IMP, etc)? If it's to replace BD, it's obviously vital that it be able to read BD's ".html0" storage format so that books can be transferred to it from BD.

[HarryT]

Originally Posted by kovidgoyal

Consider doing it in python rather than C++, much faster lead times and much easier long term maintenance.

Forgive my ignorance, but the main thing that distinguishes BD from the other tools is its GUI book editor. Can one write GUI apps in Python?

[kovidgoyal]

Originally Posted by HarryT

Forgive my ignorance, but the main thing that distinguishes BD from the other tools is its GUI book editor. Can one write GUI apps in Python?

Yes. libprs500's GUI is written in python for example. Indeed, the OP was talking about using the Qt toolkit for the GUI, you can use Qt from python.

@Gudy
I don't think we need another format. You can achieve full semanticity just using CSS classes with XHTML.

[kovidgoyal]

To address your actual question about features: I guess as a first stage you'd want to implement block level formatting with the user able to apply semantic information to each block as well as basic inline formatting (bold, italic, etc.). Then you'd want to add support for links and embedding images and fonts. At that stage you achieve feature parity with BD, at least as far as book editing features are concerned. Then you start writing input/output plugins. If you work in python, you can get a few for free from libprs500.

[HarryT]

Originally Posted by kovidgoyal

Yes. libprs500's GUI is written in python for example. Indeed, the OP was talking about using the Qt toolkit for the GUI, you can use Qt from python.

Thanks, Kovid; I didn't know what "QT" was.

[llasram]

Originally Posted by Gudy

Or are there ways to denote poems, epigraphs, citations, etc. semantically in xhtml? If not, the internal format should probably be closer to something like FB2, except perhaps richer.

kovidgoyal already hit this one, but I'll kick it up another notch. XHTML already is already semantic. The <h1/> tag doesn't mean “large bold font with surrounding vertical whitespace,” it means “top-level heading.” In addition to the semantic meaning of the tags themselves, XHTML allows each tag to have a “class” attribute, which may contain a whitespace-separated list of one or more class names. CSS can then be used to apply a particular style to elements with particular tag-types, wparticular classes, particular tag-class-pairs, tags and classes nested in particular order etc.

The class names used can be ad hoc and document specific, or one can develop a set of standard class names and re-useable CSS stylesheets referencing those names. The latter approach is essentially what is known as a “microformat.” With this approach a tool could define a standard set of entities like poems, epigraphs, etc., then define how it would semantically represent those in each file format it supported. With enough effort :-) such a tool could even cleanly round-trip between very different file formats.

[Dave Berk]

Python. Much shorter devlopment cycle. Many Packages already available. In additon, Python excel at text proccessing (I'm studing Python myself at the moment, can't believe how easy it is to write something quick compared to c++).
Also, you probably know this, but if you go QT/PyQT you have to make your code GPL.

[balok]

Originally Posted by HarryT

Forgive my ignorance, but the main thing that distinguishes BD from the other tools is its GUI book editor.

Extremely ugly and counter-intuitive GUI, and Windows-only. Two good reasons for a replacement.

[Jeff Duntemann]

What I really need is probably a little more than a 500-hour project, fersure (especially if executed in C++) but here's the gist: I'd like to have a way to generate a fully paginated pbook print image (basically, a PDF) as well as all the major reflowable ebook file formats without losing pbook page equivalence.

In other words, I want there to be page markers in my reflowable ebooks that map to page boundaries in my pbooks. I know that most of the reader utilities in their current releases won't know what to do with the page markers (which is their bad--they should have had them from the beginning) but I have hopes that vendors of reader programs will come to their senses and allow end-users to jump to numbered page locations in a ebook independent of font size or any other display parameter. If there's a page 42 in a pbook, there should be a way to quickly and easily jump to the equivalent spot in an ebook edition of the pbook, a spot independent of text flow.

This pretty much requires a tagged PDF file as an input if you're talking about laying out books in one of the major publishing apps like InDesign. I'm pretty sure that .epub/IDPF has the machinery to represent a paginated print image with all elements semantically marked, but until InDesign, Quark, and Frame can output an IDPF-compliant file of some kind, publishers wanting to generate print images as well as reflowable text files are stuck with tagged PDFs.

One of my nightmares is a future day when I can't cite a passage in an ebook from print because there's no standard human-readable way to specify a location within the ebook. Print and digital will be coexisting long after I'm dead, and I haven't yet figured out how to make print and digital coexist without relying on page numbers. There's a lively and interesting thread on this topic elsewhere in this forum that spun off some good insights (as well as a certain amount of heat):

Page numbers in ebooks for scholarly research?

I'm seeing pieces of a solution all over the place, but no one has pulled them together yet. You could do worse than be the first. (And whatever you end up doing, please keep us informed!)

[JSWolf]

Jeff, how do you handle differing page numbers in say a hard cover vs a paperback or even a different edition where page numbers change?

With the Sony Reader 500/505, you can specify the location in a human-readable way very easy like this... Page 225 size small. That means it's starts on page 225 when the font is set to small.

If you can deal with differences in page number variations in differing paper versions, I don't see how the eBook edition will be that much more difficult. Well at least with LRF format eBooks it should not sice we do have proper page numbers displayed.

The problem with page number tags in an eBook to tryt o make it match the pBook (IMHO) won't work all the time. You have an eBook that matches the paper edition as it is now. Then a different edition with differing numbers is used, the eBook no longer matches. What do you do then? The best idea (IMHO) is just to cite from the eBook's page number and font settings to know how to get back to that point in the book.

[tompe]

Originally Posted by JSWolf

Jeff, how do you handle differing page numbers in say a hard cover vs a paperback or even a different edition where page numbers change?

With the Sony Reader 500/505, you can specify the location in a human-readable way very easy like this... Page 225 size small. That means it's starts on page 225 when the font is set to small.

That will not work since there is no guarantee that the small size or the pagination will be the same after a firmware update or with the next model of the Sony Reader.