Mobileread
ePub creation tools : what's missing ? wishlist / dialogue
#1  zelda_pinwheel 01-23-2009, 12:26 PM
We've been having an interesting discussion in the french forum recently about what is missing in the apps we currently have available to us for creating epub files (i'm talking about editors, not converters), and what we wish we had. In other threads, at least 2 people (that i have seen) have mentioned their intentions to write an epub editor. In still other threads, there have been references to various details that could be done better. calibre is great in many ways, but it's not a fully-featured editor. feedbooks does a brilliant job making valid code and hierarchical structure, but a lot of people want an offline app, and feedbooks doesn't handle images yet.

So, I thought I would create ONE THREAD TO RULE THEM ALL where users can list their desiderata and any interested developpers could discuss what is possible / not possible, their intentions, etc. With a little luck we might even end up creating the ONE APP TO RULE THEM ALL right here ! wouldn't that be brilliant.

Here to start are some of the things we want as users and creators of epub books, taken from the discussion in french in this thread. Please feel free to add your own, and I hope the developpers will be interested in participating / responding as well !! Valloric, llasram, kovid, wallcraft, Komenor, et al. i'm thinking of you, for example. (<-- non-exhaustive list !!)

DESIRED FEATURES

1. epub files must be valid (html tidy, epub check...) and conform to best practices.

2. the editor should be able to accept multiple html / xhtml flows and create one document with a hierarchical TOC. It should also be able to accept one html flow and semantically parse the hierarchy of the document (part, chapter, section...) according to the tags used (h1, h2, h3, etc.), creating logical divisions for a properly structured epub document and a hierarchical TOC, the way that feedbooks does.

3. It should be able to handle images and relatively advanced css markup (dropcaps, for instance).

4. Ideally, it should be accessible even to users with no knowledge of html / css code with a full wysiwyg UI, although advanced options should be available if you do know the code (direct code editing should be possible), again similar to the feedbooks interface.

I'll probably have more to add later but i've got to go for the moment, so i'll stop here and open the discussion. What do you want from an editor ? i'll be looking forward to seeing what comes out of this !
Reply 

#2  Jellby 01-23-2009, 12:53 PM
Since I like writing my XHTML and CSS code by hand, I won't ask this from an editor, but I would appreciate a user-friendly way to generate and edit the opf (metadata, manifest, spine, guide) and the ncx (hierarchical table of contents) files.
Reply 

#3  GeoffC 01-23-2009, 02:05 PM
5. Choice of end formats, to cater for readers that do not support ePub.

6. Pick and chose title-page image.
Reply 

#4  brewt 01-23-2009, 02:05 PM
Font Embedding. The only thing that'll do that off-the-shelf now is Indesign, and well, that's the only thing it does "well".

Macros, search & replace (not just text but styles, fonts, sizes, etc), grammar checker, spell-checker, target viewing application compensation, multiple format input & output, auto paragraph re-justification & hyphenation, multiple language dictionaries, built-in browser, metadata management, multi-style select, discontinuous select, table generation/correction, cross references such as indicies and footnotes, rss feeds....

You said "killer app", didn't you Z?

-bjc
Reply 

#5  Valloric 01-23-2009, 02:13 PM
Quote zelda_pinwheel
So, I thought I would create ONE THREAD TO RULE THEM ALL where users can list their desiderata and any interested developpers could discuss what is possible / not possible, their intentions, etc.
This is a very good idea.

Quote zelda_pinwheel
1. epub files must be valid (html tidy, epub check...) and conform to best practices.
I've been thinking about this and writing down ideas in my "epub editor idea book"... there are certain problems here.

For one, we have the epub standard. Naturally, all editors should output valid epub, that's a given, but the best practices... currently, the Sony Reader--more specifically, mobile DE--has limits on chapter length (content file limit is 300KB). While this is unfortunate, I can live with it. But there are other problems and flukes of mobile DE that one has to take into account. The page numbers on the side, for instance. One needs to add margins so the numbers don't overlap the text, etc.

So a standards compliant epub may not work in mobile DE, and if it does, it may not look as nice as one specifically tailored to it. And I'm not blaming DE on certain limitations (like the 300KB limit) that are the result of the platform it runs on. Other epub reading applications for the Reader (or other devices) would probably hit a similar wall.

My current working idea is this: the editor exports two types of epub files. Both are standards compliant. One follows the standard and nothing else. No size limits, no special margins etc. Pure epub, without any consideration for the reading application or the platform. Let's call this "Standards Epub".

Then there's the second output option. This epub type is also fully compliant, but has the size limitations, special margins and other necessities for an enjoyable read on something like the Sony Reader. Let's call this "Mobile Epub".

I know no one likes the idea of two different epub files. One risks the creation of a sub-format. But I don't see a way around this. A purely standards compliant epub is a must; current practical limitations may (and will) disappear with time. But one must also be realistic: there's no point in high-horsing around with compliant epubs that nobody can read on portable devices like the Sony Reader.

I am very much interested in what other people think about this.

Quote zelda_pinwheel
3. It should be able to handle images and relatively advanced css markup (dropcaps, for instance).
I've been following the dropcaps thread(s), and it's a good example of why I would want an editor to export two kinds of epub files: one that follows the standard, and one that's tailored around flukes and idiosyncrasies of certain reading software.

Quote zelda_pinwheel
4. Ideally, it should be accessible even to users with no knowledge of html / css code with a full wysiwyg UI, although advanced options should be available if you do know the code (direct code editing should be possible), again similar to the feedbooks interface.
My working idea is to have a WYSIWYG interface, but with a "view code" view, like for instance in Dreamweaver. If someone wants to mess with it directly, they should be able to.
Reply 

#6  kovidgoyal 01-23-2009, 02:19 PM
1. and 2. are incompatible.
Reply 

#7  kovidgoyal 01-23-2009, 02:43 PM
Also I think you need to more clearly define what the use case is for this tool. Is it for authors who want to write books, or is it for proofreaders who want to touch up and convert existing books.

If the former, far more important that the features you have outlined would be features to support actual writing, like for example, keeping notes associated with characters/places/events.

If the latter then all that's needed is a wrapper around any good html editor with a wyswyg mode.
Reply 

#8  Valloric 01-23-2009, 03:04 PM
Quote kovidgoyal
If the former, far more important that the features you have outlined would be features to support actual writing, like for example, keeping notes associated with characters/places/events.
Who in their right mind would use an ebook editor to actually write a book? The editor I'm thinking of is for proofreaders and copyeditors.
Reply 

#9  zelda_pinwheel 01-23-2009, 03:14 PM
Quote Valloric
This is a very good idea.
i'm glad you think so ; i had you in mind when i thought of it.

Quote
I know no one likes the idea of two different epub files. One risks the creation of a sub-format. But I don't see a way around this. A purely standards compliant epub is a must; current practical limitations may (and will) disappear with time. But one must also be realistic: there's no point in high-horsing around with compliant epubs that nobody can read on portable device like the Sony Reader.

I am very much interested in what other people think about this.
well, you're right, this isn't the optimum situation, however it seems a reasonable compromise to me. particularly since the "standards epub" can also be used for archival purposes and as a source format for conversion to other formats as needed. i'm not an expert though ; i'll be interested to see other reactions.

Quote
My working idea is to have a WYSIWYG interface, but with a "view code" view, like for instance in Dreamweaver. If someone wants to mess with it directly, they should be able to.
right, that's rather the idea i had in my head as well.

Quote kovidgoyal
1. and 2. are incompatible.
why are 1 and 2 incompatible, kovid ?

Quote kovidgoyal
Also I think you need to more clearly define what the use case is for this tool. Is it for authors who want to write books, or is it for proofreaders who want to touch up and convert existing books.
the users of this tool as i see it are very much the *latter* case you describe : they are the same kinds of people using BookDesigner or ETI's eBook Publisher or Mobipocket Creator today, but who want a good tool for making epub files. so really closer to dreamweaver than to word or any writing tools. i imagine they would *already* have the finished text, either PD texts or their own manuscripts, and just want to turn them into ebooks. so, yes, a wrapper around a good html editor with a wysiwyg mode. but i think there are some particularities specific to epub that would need to be addressed (creation of the different file types, creation of the epub container...).

anyway this discussion looks to be off to a good start ! i'm glad to see it !
Reply 

#10  Valloric 01-23-2009, 03:25 PM
Quote zelda_pinwheel
particularly since the "standards epub" can also be used for archival purposes and as a source format for conversion to other formats as needed.
Exactly. There are people out there who want to use epubs purely for storage.

Quote zelda_pinwheel
the users of this tool as i see it are very much the *latter* case you describe : they are the same kinds of people using BookDesigner or ETI's eBook Publisher or Mobipocket Creator today, but who want a good tool for making epub files. so really closer to dreamweaver than to word or any writing tools. i imagine they would *already* have the finished text, either PD texts or their own manuscripts, and just want to turn them into ebooks. so, yes, a wrapper around a good html editor with a wysiwyg mode. but i think there are some particularities specific to epub that would need to be addressed (creation of the different file types, creation of the epub container...).
Again, I agree completely. This is exactly how I see an epub editor: a tool that facilitates the manual creation of an epub book from pre-existing text. BD for epub... without the suck.
Reply 

  Next »  Last »  (1/11)
Today's Posts | Search this Thread | Login | Register