Future Thoughts on Getting Decent epub 3 support

[Turtle91]

Originally Posted by BetterRed

... I edit factual public domain 'papers' from government...

That's what I thought it was called, TBH. It is Preview View? Which sounds ever-so-slightly repetitive? If it's that, let's just call it Preview, period, I guess...???

How about "Pre-View"....PV


edit: just wanted to emphasize I was laughing at the possibility of "factual" and "government" being in the same sentence - nothing against BR

[BetterRed]

Originally Posted by Hitch

Anyway, back to the important stuff: I do think we need to keep some type of PASTE functionality, for those folks who are using it. No matter what we do for the rest. I can see how it could actually be useful. Hitch

That is what my "Paste Buffer" suggestion is intended to address - paste text/image/media clip etc, into an empty (maybe a pop up) Paste Buffer Panel and Save it within the epub, in the appropriate location, with an appropriate name, with an entry in the manifest etc etc. Then edit the saved epub component in the 'normal way'.

BTW what I mean by keyboard friend copying from Preview is this - I would use the mouse double click to highlight a word, then I would use ctrl/shift arrows keys to select the text I wanted and then press ctrl/c to copy - as I can do in most (all) a web browsers.

PP makes me think of certain political parties in Europe and Latin America - some are from the Loony Left but more often from the Rabid Right.

BR

[eschwartz]

Originally Posted by Turtle91

How about "Pre-View"....PV

That was my #2.
It has the advantage of ALSO being consistent.

[BetterRed]

Originally Posted by eschwartz

It has the advantage of ALSO being consistent.

In the purview of this thread at least, it appears that 'PV' was first used in post #6 by theducks - so we can blame him

[Hitch]

Originally Posted by BetterRed

That is what my "Paste Buffer" suggestion is intended to address - paste text/image/media clip etc, into an empty (maybe a pop up) Paste Buffer Panel and Save it within the epub, in the appropriate location, with an appropriate name, with an entry in the manifest etc etc. Then edit the saved epub component in the 'normal way'.

BTW what I mean by keyboard friend copying from Preview is this - I would use the mouse double click to highlight a word, then I would use ctrl/shift arrows keys to select the text I wanted and then press ctrl/c to copy - as I can do in most (all) a web browsers.

PP makes me think of certain political parties in Europe and Latin America - some are from the Loony Left but more often from the Rabid Right.

BR

Oh, boy, a Pasta Buffer!! Does it come with a Bolognese?

Seriously, I vote for the Pasta Buffer. And in honor of this thread, I further vote it be so named.

Originally Posted by eschwartz

That was my #2.
It has the advantage of ALSO being consistent.

Fine. Pre-View it is. Here endeth the Lesson.

Hitch

[st_albert]

Well, I'm glad we got that cleared up.

Though I'm a bit late to the party, I wanted to add my bleat. Namely that I don't often use book view, as the uhhh... PV does just about everything I need along those lines, including pointing out badly-formed code on the page. (it is a bit quirky about displaying embedded fonts and a few other visual things, IIRC.) Basically I wouldn't miss it if it were gone.

Having the ability to paste text from the clipboard directly into Sigil is a nice feature sometimes, though, so I support the Pasta Buffer feature.

When it comes to actually composing something I prefer to use Libre Office, and convert that to a fairly clean epub with the Writer2xhtml plugin.

To me, adding or modifying text in BV is flying blind (as to what is happening under the hood). Makes me nervous.

Albert

[CliffB]

Many of the people posting to this thread make the assumption that Sigil is always used as a final editor and tweaker before publishing to ePub format, and that book view is not needed. I work with about 25 editors and writers in small publishing companies and our original intention was also to use Sigil as a final editor and tweaker in our tool chain. In reality that is not what happens in most use cases.

In real world usage most of us have a tool chain and do use other tools such as word processors and Google Docs to originate content and then import into Sigil at some point. HOWEVER, a huge amount of modification and rewriting ends up taking place in Sigil. I can give you many reasons why this is the case if you are interested, but we always end up doing doing a substantial amount of writing in Sigil.

We DO NOT LIKE TO SEE HTML CODE AND CSS WHILE WE ARE WRITING. We write in Book View so that we can concentrate on the content without distracting HTML tags. Then we go back later in Code View and fix any html anomalies that might have been introduced by Book View. This is a small price to pay for having a pseudo wysiwyg writing interface. You can go on all day about the supposed evils of wysiwyg or wysiwym interfaces, but most writers DO NOT WANT TO SEE HTML while they are trying to concentrate on writing content. After we get the writing done we switch to Code View and fix the damage - no problem, no complaints. Yes,, it would be great if Book View was perfect and did not have any quirky behavior, BUT having Book View even with its quirks is a godsend for productivity.

Shoulda Woulda, I can hear many of the people that have already posted to this thread saying "but you should not be trying to write in Book View, etc, etc." The reality is that many people do write in Book View every day and that Book View is one of the MOST IMPORTANT features of Sigil to most writer-editors.

I wish to give a heartfelt thanks to Kevin Hendricks, Doug Massay, John Schember, Grant Drake, Dave Heiland, Charles King, Daniel Pavel, Grzegorz Wolszczak and all of the other contributors to Sigil.

You have provided us with an invaluable tool. We are small publishers and writers, many of us struggling financially. Sigil is the centerpiece and main workhorse of our publishing toolchain.

[Notjohn]

>The reality is that many people do write in Book View every day and that Book View is one of the MOST IMPORTANT features of Sigil to most writer-editors.

I can't believe it's true of MOST of us, considering the awful mess that it can create.

If the statement is true, I think it is a good reason to eliminate Book View on the ground that it tempts people to do what they ought not do.

[CliffB]

I can't believe it's true of MOST of us, considering the awful mess that it can create.

You're not hearing me,,,, It does not cause such an awful mess, especially if you learn what causes unintended consequences and avoid those operations in Book View. You quickly learn the operations that cause unintended consequences and switch to Code View for a few seconds when doing those things. Yes - this is not a perfect situation, but you don't abandon a very valuable feature just because it has some flaws that can be worked around! You also have to occasionally switch to Code View and clean things up a bit.

The part you're not understanding is that IT'S WORTH IT. We are not complaining. Book View is still a valuable and needed productivity feature, even with its flaws. Yes, if it can be improved that would be great, but don't remove it!

If the statement is true, I think it is a good reason to eliminate Book View on the ground that it tempts people to do what they ought not do.

Who are you to decide whether other users should or should use Book View?? I respect your use of the software for your application, why can't you respect our usage and not second guess what is good for other users???? If you don't want to use Book View, than don't use it. It seems strange that WE WHO DO USE IT are not complaining about it making an "awful mess", but you who do not want to use it are complaining about it!!!!

One more time - Book View is a valuable productivity feature for many users, regardless of its flaws. We know it's not perfect, but we use it every day because it helps us work more efficiently. If it doesn't help you work efficiently then don't use it.

[CliffB]

For example Book View works flawlessly for entering text and writing. The problems come from certain types of editing. Selecting text and dragging can add unwanted tags. I switch to code view to move formatted text around, edit lists and do other problematic operations.

Regardless, I can sometimes spend hours writing in Book View and pasting in text from other documents and when I finally switch to Code View and look, there is very little or nothing to clean up. I get hours of distraction-free, HTML-free writing and all I have to do is switch to Code view for a few seconds and check my work occasionally. It's worth it. Out of the 25 or 30 writers and editors I work with no one has a problem with this.

[KevinH]

No worries here... No decision one way or the other has or will be made about BV for a long time to come. When that time does come, we will certainly take into consideration what benefits BV brings before doing anything drastic.
KevinH

[DiapDealer]

Originally Posted by CliffB

but you don't abandon a very valuable feature just because it has some flaws that can be worked around!

If that was the only issue, there'd be no discussion/problem. IF (and it's a really big and distant if) Book View were ever removed, it wouldn't be because it "has flaws that can be worked around." I wish that was the only hurdle we faced. The problem is that the hoops that have to be jumped through to allow both Book View WYSIWYG editing AND Code View editing (and the synchronization between them) are getting higher and smaller all the time. We're also facing the eventual removal of WebKit (the rendering engine behind Book View--which is now deprecated, BTW) from Qt5. Which would mean another overhaul of Sigil to continue to provide Book View/BookView-editing (if we wanted to avail ourselves of the feature-improvements/bug-fixes in future versions of Qt5).

Nobody wants to go WYSIWYG-only or CodeView-only, but when the former is holding back advancements (not that that is happening yet), or features/improvements that would be relatively simple to achieve without it, then we have to consider what would be best for the majority of users (and our sanity).

But like Kevin said, there's no current plans to remove it. Just discussion. But please don't make the mistake of thinking we would ever axe it simply because it has a few flaws (or because we don't like it because we're "coders"). It's more complicated than that.

[st_albert]

Originally Posted by CliffB

Many of the people posting to this thread make the assumption that Sigil is always used as a final editor and tweaker before publishing to ePub format, and that book view is not needed. I work with about 25 editors and writers in small publishing companies and our original intention was also to use Sigil as a final editor and tweaker in our tool chain. In reality that is not what happens in most use cases.

In real world usage most of us have a tool chain and do use other tools such as word processors and Google Docs to originate content and then import into Sigil at some point. HOWEVER, a huge amount of modification and rewriting ends up taking place in Sigil. I can give you many reasons why this is the case if you are interested, but we always end up doing doing a substantial amount of writing in Sigil.

[snip]

Thanks for sharing your workflow. It was an eye-opener to me!

As my post right above yours suggests, my experience has been almost the opposite of yours. I do 90+% of my work (which is book interior design) for a single publisher whose authors and editors almost exclusively use Word or an equivalent. Only after the final edits are complete do I get a .doc file for placement into InDesign and/or conversion to epub and other formats.

Your authors must be much more tech-savvy than the ones I work with. I can only imagine the chaos which would ensue if we asked our authors to use Sigil as a word processor!

So it seems there's a whole other world out there that I had been unaware of. Horses for courses, eh?

Albert

[Hitch]

Originally Posted by st_albert

Thanks for sharing your workflow. It was an eye-opener to me!

As my post right above yours suggests, my experience has been almost the opposite of yours. I do 90+% of my work (which is book interior design) for a single publisher whose authors and editors almost exclusively use Word or an equivalent. Only after the final edits are complete do I get a .doc file for placement into InDesign and/or conversion to epub and other formats.

Your authors must be much more tech-savvy than the ones I work with. I can only imagine the chaos which would ensue if we asked our authors to use Sigil as a word processor!

So it seems there's a whole other world out there that I had been unaware of. Horses for courses, eh?

Albert

Yes, I was thinking the same thing. If we asked our clients ("our" authors, for lack of a better way to phrase it) to work in Sigil...well, that wouldn't be pretty. Our clients have difficulty in downloading files from the browser interface (we have browser-based SAS), much less downloading and installing Sigil.

We have myriad tools prior to using Sigil, but even with the fairly endless revision cycles we do, we're not working in BV. When we edit, we edit in HTML, whether that's a single HTML file (usually a section or chapter of a book), or in Sigil. I am a huge fan of Sigil, but I never use BV; I use Preview when I need it.

Offered solely FWIW. As Albert said, different horses.

Hitch

[CliffB]

To KevinH & DiapDealer:
I understand the issues and appreciate your insight. Hopefully there will be an alternative to WebKit before it is removed from QT5, or other unsurmountable problems come up. If Book View eventually becomes too problematic an alternative would be for us to continue to use an older stable version of Sigil for book view style editing and switch to a newer version for other editing. Perhaps later we will be in a position where we could contribute (coding wise).

To st_albert & Hitch:
Yes, we are a very different type of user, but there are a many of us out here. We are small independent publishers and authors. Personally I work in the Seattle and Portland areas but sometimes work with OpenStax CNX in Houston. We are quite tech savvy, most of us can hack HTML, CSS, JavaScript. However, we do not like to hack code while we are writing because it is a huge distraction and reduces productivity (hence the value of Book View).

I have 4 books out now for which I used Sigil as the final editor. Each one was written in LibreOffice or PanDocs Markdown and I used Google Docs for research and collaboration with other authors. My intention was to import them into Sigil as the last stage of the tool chain and then do the final edit. Of course they dragged on for another 6 months to a year and were substantially rewritten AFTER being imported to Sigil. I would say that 1/4 to 1/2 of the total writing was done in Sigil when all was finally said and done.

In your usage case, you are the final editor?? In this case the author has finished and passes the work to you for final editing. In our case we are the author AND the final editor.