Future Thoughts on Getting Decent epub 3 support

[DiapDealer]

The problem with "hiding" html tags in something like Code View is that it still doesn't address one of the biggest hurdles faced in synchronizing the current Book View with Code View: accurately/consistently "guessing" the real cursrsor postition in a rendering of the actual (and often times very convoluted) html markup. Hiding markup would only likely exascerbate the problem. When faced with a nightmare of nested spans, divs and blockquotes, where IS the cursor, really, when you place it next to the letter 'V' in a wysiwg view? Next to the innermost preceding inline element? The outermost block-level element? Somewhere in between them? This has to be known (or "best-wild-assed-guessed-at") to be able to convert your wysiwyg changes into html that's then merged (with any luck--gracefully) back into the pre-existing markup. This issue is also what makes splitting/merging in Book View ill-advised.

Sometimes I think people don't understand that there is no seperate, text-only version of your document that exists within Sigil to be edited. There is only the markup (CV), and then the Webkit rendered markup (BV) that gets crammed into a text editor--the changing of which requires figuring out the best (often meaning least destructive) method of incorporating those "blind" edits back into the real document.

A wysiwyg editor in which the ability to edit (or even influence) the underlying markup is entirely forfeited .... piece of cake.

A code view editor which provides the ability to produce markup exactly the way you want it (while being able to preview your work--but not change anything in it) .... another piece of cake.

The ability to do either without depriving both wysiwyg users AND codemonkeys of features that would otherwise be relatively simple to impliment, can actually be quite the nightmare. Most of it down to cursor position and Webkit quirks/bugs that don't allow certain things to survive the transition.

[Thasaidon]

Originally Posted by DiapDealer

A wysiwyg editor in which the ability to edit (or even influence) the underlying markup is entirely forfeited .... piece of cake.

A code view editor which provides the ability to produce markup exactly the way you want it (while being able to preview your work--but not change anything in it) .... another piece of cake.

Purely a brainstorming idea for discussion

If each of the above are relatively easy is it be possible to have them as Sigil "modes" and have the ability to toggle between the modes?

[Toxaris]

Originally Posted by Thasaidon

Purely a brainstorming idea for discussion

If each of the above are relatively easy is it be possible to have them as Sigil "modes" and have the ability to toggle between the modes?

That is what we already have, to some extend. The source must be the same, to prevent syncing errors or missing content.

[JSWolf]

Originally Posted by CliffB

Just a thought: Perhaps instead of wysiwyg, some type of simplified wysiwym (what you see is what you mean) interface is a viable compromise? Would this be easier to implement? Is there an existing implementation that could be adapted?

I don't want a Sigil trying to figure out what it thinks I mean. I want it to show what I do mean. Then I can see if I've done anything incorrectly or not.

[JSWolf]

Would it be possible to have a book view (none-editable) next to the code view so we can see what we are doing while we do it (like Calibre has). This is not to replace book view.

[Doitsu]

Originally Posted by JSWolf

Would it be possible to have a book view (none-editable) next to the code view so we can see what we are doing while we do it (like Calibre has). This is not to replace book view.

This feature already exists: View > Preview or F10.

[Notjohn]

Originally Posted by JSWolf

Would it be possible to have a book view (none-editable) next to the code view so we can see what we are doing while we do it (like Calibre has). This is not to replace book view.

Isn't that what we have in Preview Pane?

[Thasaidon]

Originally Posted by Toxaris

That is what we already have, to some extend. The source must be the same, to prevent syncing errors or missing content.

But only to some extent.

To make things clearer you would have a "bookview" which has no ability to edit (or even influence) the underlying markup

OR

a Code view which could be used with the Preview pane which cannot be edited.

There need be no cursor syncing when switching modes. It is this syncing which has been said to cause many problems.

[theducks]

Clicking in Preview will Sync the Code view to the same paragraph.
That meets my needs.

Get me to the code (right now... )
It does this well

Preview pane can be undocked for those with multi-monitors

[DiapDealer]

Originally Posted by Thasaidon

There need be no cursor syncing when switching modes. It is this syncing which has been said to cause many problems.

Allowing an either/or mode would still entail a massive overhaul of the codebase and would introduce even more complexity and more bugs. We've just achieved some stability after a major overhaul and would rather not have to do that again for a while.

It's not so much "synching" that's the problem (though I know I introduced the term). It's cursor position (knowing where the cursor is being placed in the "real" document (html) when editing in the rendered Book View text, and elements that can't survive (or exist) when turning that rendered Book View text back into html. Most of this is handled by Qt, by the way. Meaning we're basically at the mercy of its bugs and quirks.

But so far, we've been able to introduce limited epub3 support (and keep working to add more) without needing to sacrifice Book View editing. So unless we smack into an insurmountable obstacle, there will be no push to remove Book View anytime soon (if ever). Just so long as people understand that continuing to make extensive edits in Book View will eventually bite you in the ass (even if you're very careful). It's just the nature of the beast.

I, personally, am uncomfortable promoting Sigil as a WYSIWYG editor when I can't, in good conscience, recommend that anyone actually use the WYSIWYG interface for editing. I get tired of providing support that basically consists of, "don't do that in Book View." It's not a real answer (even though it's the ONLY one I can give).

[CliffB]

DiapDealer said:

I, personally, am uncomfortable promoting Sigil as a WYSIWYG editor when I can't, in good conscience, recommend that anyone actually use the WYSIWYG interface for editing. I get tired of providing support that basically consists of, "don't do that in Book View." It's not a real answer (even though it's the ONLY one I can give).

I can sympathize with this completely.

The majority of what we do in Book View mode is cutting and pasting of paragraphs. We know better than to cut and paste sections with mixed tags such as div and span sections. Since most of our material is in simple paragraphs this means we can edit for hours without an issue coming up. We know which sections have mix tags and switch to Code View for those edits. Sure, every once in a while we screw up and end up with mangled tags that must be fixed.

Here is an idea - How about reducing Book View functionality so that it can only edit paragraphs and other areas that do not cause a problem? In other words have a Book View with reduced but less buggy functionality. For other types of editing you would simply switch to Code View.

In this case we could still use Book View for the things that it does well and it would simply not have the problematic functionality available. We wont be losing anything because we avoid the problematic functionality now anyway.

Just an idea.

[KevinH]

Updated 20160103.
Based on master at https://github.com/kevinhendricks/Sigil

Here is a status update on adding basic epub3 support in Sigil.

For the next release, we have made Sigil epub version "aware" so that things like Mend(), Splitting Files, Adding Existing Documents, Index Generation, NCX creation, and "creating a new ebook from scratch" are all now do the right thing for the specific epub version. In other words, using these features should no longer break an epub3.

Here is our progress on selected items form the first post in this thread...

1. add support to Gumbo to always use nbsp / x160 entities depending on epub version being used

done and setting of the proper doctype too

2. pull pretty print out of the Clean menus and create a prettyprint function or plugin

done

3. create an new metadata gui to allow editing both epub2 and epub3 metadata

work on this is next on the agenda

4. add a nav generator (similar to the toc generator).

done - also an "Update Manifest Properties" tool has been created as well

6. try to add support for smil

Basic support added via plugins but native support for the SMIL file type is planned for next after the MetaData GUI editor

10.add support for running long python scripts internally to Sigil without slowing the ui

done - this is how nav generation from the ncx and guide is actually handled

11. add buttons or keyboard accelerators to launch user configurable plugins with minimal gui overhead.

still planned but plugin autostart and autoclose support will help simplify plugin running

So there is still lots to do but we are moving forward.

KevinH and DiapDealer