ePub creation tools : what's missing ? wishlist / dialogue

[Valloric]

Originally Posted by mtravellerh

If you do that (5), people like Coolmicro will get up and shout again that the resulting epub is not conform to standard and that the html code is not "clean". (I really do not care about "clean or dirty" code myself, as long as it does what it has to do, like Calibre does for example). So I am all for it.

An epub file either conforms to the standard, or it doesn't. It is not a matter of opinion.

On "clean" vs "dirty" code, this is very much a matter of opinion, so it depends on the person reading the code.

[kovidgoyal]

Actually, I've been thinking about this problem on and off and to me it seems like the whole concept of WYSWYG editors is flawed. Instead I've been thinking about a side-by-side editor.

The editor will allow you to edit txt files in a simple lightweight markup language like rest or markdown (it will have GUI controls to make it easy, rather like the editor we use to make posts to mobileread). As you make changes the result will be automatically updated and displayed in a pane to the side of the editor pane.

So editing books will be about as hard as making posts on mobileread.

[tompe]

Originally Posted by kovidgoyal

Actually, I've been thinking about this problem on and off and to me it seems like the whole concept of WYSWYG editors is flawed. Instead I've been thinking about a side-by-side editor.

Of course it is. Emacs is the ultimate editor and LaTeX the ultimate markup language...

I think the approach you describe is a good approach.

[Jellby]

Originally Posted by brewt

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".

Font embedding (or at least basic embedding) seems to be quite simple. I guess WISIWYG support is a different thing.

Originally Posted by Valloric

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 would have different configurable parameters, like maximum file size, maximum nesting level, whether or not to support some optional features... and have the software issue a warning if these limits are exceeded. It shouldn't be so hard to have a "Warn if text files are larger that ____KB" setting.

[mtravellerh]

Originally Posted by zelda_pinwheel

out of curiosity, Valloric, have you seen the feedbooks wysiwyg editor ? i HIGHLY recommend you take a look at it and at how the book creation process is handled ; it is excellent, and it is easily accessible even to people who know nothing at all about html / css, however also gives access to the source code for more knowledgeable users. really, in my mind, the tool i would like would be very close to the feedbooks interface, with just a few modifications. notably i definitely want to be able to insert images, which feedbooks does not yet support.

Hmm, yes. Actually, like I said elsewhere, if one were able to get Hadrien's codes, one could easily run an internal webserver with those on it and have an "offline" app (with a few addons for image manipulations, for example)

[Valloric]

Originally Posted by kovidgoyal

Actually, I've been thinking about this problem on and off and to me it seems like the whole concept of WYSWYG editors is flawed. Instead I've been thinking about a side-by-side editor.

The editor will allow you to edit txt files in a simple lightweight markup language like rest or markdown (it will have GUI controls to make it easy, rather like the editor we use to make posts to mobileread). As you make changes the result will be automatically updated and displayed in a pane to the side of the editor pane.

So editing books will be about as hard as making posts on mobileread.

That sounds like a WYSIWYG editor with a side pane code view, and you can only edit the code.

But I get your idea. It sounds nice. It possibly has a few problems... for instance, you're display the same text twice on the screen. Seems more than a bit redundant. And if you make the display or markup view collapsible, you get a WYSIWYG editor again.

[mtravellerh]

Originally Posted by Valloric

That sounds like a WYSIWYG editor with a side pane code view, and you can only edit the code.

But I get your idea. It sounds nice. It possibly has a few problems... for instance, you're display the same text twice on the screen. Seems more than a bit redundant. And if you make the display or markup view collapsible, you get a WYSIWYG editor again.

What I hate in NVU for example, is the way it just plays around with your code. For example the mobi pagebreak code will be changed without any notice to you. Therefore Kovid's idea with the permanent code view seems like a great idea to me. For advanced users, you could easily do a search and paste over the whole file or files and work a lot faster while still seeing the result of your work in real time.

[Valloric]

Originally Posted by Jellby

I would have different configurable parameters, like maximum file size, maximum nesting level, whether or not to support some optional features... and have the software issue a warning if these limits are exceeded. It shouldn't be so hard to have a "Warn if text files are larger that ____KB" setting.

This is the "presets over options" debate.

Naturally, one would want to provide advanced options for advanced users, but the more options you provide, the higher the chances of someone screwing up their options that end up making epubs that work for them and not for anyone else.

I'm thinking of the mobileread community here, and the upload forum.

But the advanced options should be there for those who want them... just tucked away a bit.

[Valloric]

Originally Posted by mtravellerh

What I hate in NVU for example, is the way it just plays around with your code. For example the mobi pagebreak code will be changed without any notice to you. Therefore Kovid's idea with the permanent code view seems like a great idea to me. For advanced users, you could easily do a search and paste over the whole file or files and work a lot faster while still seeing the result of your work in real time.

Hell if you want to able to see exactly what each and every keystroke or action you perform does, that's easy. WYSIWYG editor with a side pane code view that updates the code with each action in the main view pane. That's already in my design document, only the panes are horizontal.

But you should be able to turn off the code view and work in design view exclusively. I don't need to see all of the text duplicated on the screen all of the time.

[zelda_pinwheel]

it occurs to me that not everybody on this forum is a native english speaker and maybe some of them aren't familiar with some tech jargon, so for the sake of clarity (just in case anybody doesn't know) :

WYSIWYG = What You See Is What You Get

it means an interface which allows you to click on a button marked "B" (like in the MR reply box) and shows you the result this way :

this text is bold.

and not this way :

this text is <strong>bold</strong>

[mtravellerh]

Originally Posted by Valloric

Hell if you want to able to see exactly what each and every keystroke or action you perform does, that's easy. WYSIWYG editor with a side pane code view that updates the code with each action in the main view pane. That's already in my design document, only the panes are horizontal.

But you should be able to turn off the code view and work in design view exclusively. I don't need to see all of the text duplicated on the screen all of the time.

True. And the other way around (only source view) What about the RegEx (oh: taking Zelda as a model: RegEx=Regular Expressions) integration? That one is very important for me (to get rid of the pagenums in PG source, for example).

[kovidgoyal]

Originally Posted by Valloric

That sounds like a WYSIWYG editor with a side pane code view, and you can only edit the code.

But I get your idea. It sounds nice. It possibly has a few problems... for instance, you're display the same text twice on the screen. Seems more than a bit redundant. And if you make the display or markup view collapsible, you get a WYSIWYG editor again.

Yeah but coding a wyswyg editor is a lot more work, for relatively little benefit. And I would envisage the preview pane being collapsible, not the code pane.

And I would urge you to consider makeing the panes vertical since most ebook readers are vertically oriented and in any case most people prefer to read text in narrow columns

[=X=]

I've yet to work with a tool that worked well when the user was allowed to modify the source as well as work in a WYSIWYG environment. Either the user is forced to work with both modes or has to choose one view. In other words most of these editors tend to favor one style of edition or implement both poorly.

When I created the BookCreator tool I wanted to be able to use a really good editor and not have to worry about HTML, format shift issues. I just wanted to edit the book how I wanted it to look. Kovid, calibre does a fantastic job format shifting HTML to LRF/ePUB/LIT/ and more to come.

Right now the direct of this thread is geared towards format shifters not editors or writers. But the demand for a good editing en ePublishing tool is there I’ve had serveal athuors. conatct me thanking me for the BookCreator tool and how it facilitates their eBook creation process withouth having to get down and dirty in the code.

If the developers on this group would really like to build an end all ePublishing tool I'd like to see us create a Plugin around Open Office, an excellent Word Processing tool.

Going this route we would build a house on a solid Word Procesing foundation and can easily extend the UI to include other ePublishing features. Such as a GUI TOC builder, format(HTML/LIT/ePUB…) imports, etc..

Just my 2cents
=X=

[mtravellerh]

Originally Posted by kovidgoyal

vertically oriented

(sorry for my perverted thinking)

When I do proofreading, I prefer to have the window panes side by side

[Valloric]

Originally Posted by mtravellerh

True. And the other way around (only source view) What about the RegEx (oh: taking Zelda as a model: RegEx=Regular Expressions) integration? That one is very important for me (to get rid of the pagenums in PG source, for example).

Only source view --> editing in Notepad

RegExes are important and should be included. I'm not sure if they'll make it to the first release (which is probably a few months off), but they're something that is definitely on the list.