Future Thoughts on Getting Decent epub 3 support

[st_albert]

Originally Posted by DiapDealer

While getting a feel for various users' workflows is invaluable (and in a few cases enlightening) to any rational consideration of Sigil's future (development-wise), I'd like to make a plea that it be limited to a more general workflow discussion--in relation to this thread. Detailed workflow discussions where Sigil only represents a small piece of the puzzle are probably best located in the Workshop forum.

As I said; It's been enlightening--and I'm not upset or anything, but I think we're rapidly heading toward "deserves its own thread" territory if we're not careful.

Mea culpa, mea culpa, mea maxima culpa.

Albert

[Hitch]

Originally Posted by DiapDealer

I admit it, you're not entirely wrong.

Yabbut, you know (where's Cap? Cap was with me, back when I named the original 3-hour jobbies, and he helped me name the other two), it was fun back then. Singing "a three hour tour," just kinda fit with Mobi-makin' with MBPC. Alas, that three-hour thing didn't last long, but...{shrug}.

But the other revelation was that someone would actually use Sigil to compose books with. Just seems so counter-productive to me--but I don't want to judge.

I concur, but obviously, it works for him and his authors. I asked him why he didn't use something like Jutoh or Scrivener, for all that round-the-world editing stuff, but I'm quite sure that they have their reasons.

Originally Posted by st_albert

Mea culpa, mea culpa, mea maxima culpa.

Albert

Et tu, Albert?

Hitch

[CliffB]

Back to Sigil Features and why we compose in Sigil

DiapDealer said:

But the other revelation was that someone would actually use Sigil to compose books with. Just seems so counter-productive to me--but I don't want to judge.

I guess it depends on the type of books. The books we are doing are mostly technical books with many images. The last one had over 400 images. I would not use Sigil to compose a fiction book or any book that was mostly text, but with an image intensive technical book you really need to be looking at what the final product will look like. Most of our books are sold as eBooks, a much smaller amount are print. Major decisions on content are based on seeing the book in ePub form. This is especially true when optimizing the file size. With Amazon charging delivery fees based on the file size of ebooks, the file size is a major factor. In a perfect world this would not be the case, but hey. One of our books has 343 images (not little clips, I mean large images) and an Amazon paid deliverable size of 3.68 megabytes. This can't be done after the fact in the final editing stage, the book (and every single image) must be optimized during composition to achieve this. Ignore this and delivery fees will eat up most of the profits.

Another factor is the user experience of the ebook with reflowable text and lots of images. There are many things that seem fine in draft form (in LO or Word) and then look horrible when looking at the eBook on different readers. Simple editing and formatting will only solve some these issues. We routinely have to make major compositional changes and content changes before everything looks good or at least a decent compromise can be arrived at.

In our experience these types of books are better composed in Sigil. Image intensive books done in another tool or editor do not import or convert correctly and need so much tweaking that it is better to just do it from the beginning in Sigil.

Once we have our finished ePub, for conversion to PDF for Print we have several viable options, in each case we have to make some adjustments and substitute higher resolutions images. But doing it the other way around is a no-go. We have tried starting with the print versions first and converting to ePub in editors like InDesign, Scribus, Framemaker, Oxygen XML, etc. Not worth the trouble, these programs generate HUGE file sizes. We get a better results and workflow by starting with the ePub in Sigil and then working from there.

[CliffB]

So, this relates to Book View because when compiling an image intensive book often times the images will elicit additional writing or rewriting that must be done. Sigil gives us the nuts and bolts in Code View for optimizing HTML, CSS and image sizing AND gives us Book View, a distraction free writing environment for adding additional content when needed. We are wearing two hats but not at the same time, we switch back and forth. We are an HTML coder and image optimizer half the time and a writer the other half. Sigil lets us swap back and forth in the same environment by using Book View and Code View. It works great.

[Turtle91]

It seems like you have two concerns: 1) Adding content, and 2) Seeing how
the book looks.

1) You can just as easily type in the code view window. Practically the only thing CV doesn't do that BV does is automatically wrap <p> tags around your paragraphs. That is easily fixed by highlighting (triple clicking somewhere in the paragraph - or clicking on the number to the left) the paragraph and hitting the "p" button.


All other styling functions (italics, bold, sup, sub, etc) work the same in either view.


2) Have you tried using PreView in your workflow??

You can use preview always docked to a side of the screen, or even undocked as its own window. You can resize PV to simulate any size device to check how the book looks and reflows... If you have a second screen you could even drag the window to it... You can even toggle between the two modes by double clicking the header - or hitting F10. The possibilities are endless!!

Docked to the right:



It's own window:

[CliffB]

Thanks Turtle91, your question is getting to the crux of the matter. I think that most of the people responding to this thread have the useage case in mind where Sigil is being used as the final editor. The usage case of using Sigil as a content creation tool and an editor at the same time comes as a surprise. As I was talking about in the last post we use Sigil for content creation and editing simultaneously. Regardless of whether Sigil was originally designed with this use case in mind or not, it works well for us. There is no better tool or workflow that we have been able to find.

It seems like you have two concerns: 1) Adding content, and 2) Seeing how
the book looks.

1) You can just as easily type in the code view window.

Since we are doing lots of writing and rewriting in Sigil for the reasons I was talking about in the last post, it is desired to have a distraction free writing mode. If we were doing only editing it would not be so important, but we are doing a considerable amount of writing and content creation in Sigil. Many people are surprised by this and have the opinion that Sigil was not designed as a word processor, but just because we do a substantial amount of writing in Sigil does not mean that we think it is a word processor. Your work flow of writing in one stage (in a word processor) followed by importing to Sigil and editing the HTML in Sigil is not the same as our work flow. In our workflow we are doing much of the writing and of course the HTML editing in Sigil. It is a different workflow. It works for us.

Code View is horrible for distraction free writing. Not for any technical reason, but simply because looking at HTML is distracting when we are trying to concentrate on writing. Preview mode helps, but in preview mode the Code View panel is still what you end up looking at while typing. Code View with Preview is not a distraction free writing interface, HTML code is still in your face (and inevitably you start thinking about it and tweaking it instead of thinking about and visualizing the content). We would rather write in Book View for 30 distraction free minutes at a time and then occasionally switch to Code View and do any necessary HTML and CSS tweaks.

We also frequently cut formatted and unformatted text from other windows and paste it into the Book View window in Sigil, so we want to use Sigil (in Book View) in one window, side by side with LO, Word or Chrome in another window. This two window setup is clean and allows us to concentrate on writing, cutting & pasting a large amount of content quickly. If we start screwing around with HTML editing at the same time as writing our concentration goes out the window and productivity is majorly impacted. We have tested this extensively. Contrary to what many people think, human brains do not multitask very well. There is a large body of recent research to back this up. Writing content while HTML editing is not productive, they should be done one at a time.

Also in Code View with Preview we can not cut and paste formatted text the same way, because pasting formatted text is a feature of Book View. Another thing is that using Code View with Preview gives you three main panels or windows, Code View, Preview and then LO, Word or Chrome. We don't want three windows. On our laptops without dual displays we want two windows side by side not three.

In our use case alternating between Book View and Code View really is what we want to do. Book View is a major reason why Sigil is much better than the Calibre editor for us.

[Hendrixxxxxxxx]

Wondering if it would be possible/easy/feasible to invisibilize (if that's not a word, it should be!) the html tags in code view (with maybe image tags excepted) - so they are still there, but invisible. Code view would look like a simple text editor while the tags are invisible.

This would get around the issue of trying to read around tags for those who compose in Sigil (maybe with automatic </p><p> tags inserted for each carriage return).

So, for those who want/need to compose in Sigil and are currently using BV to do so would be able to compose in CV, and have PV open alongside....with the ability to turn the visibility of tags on and off as necessary. They could either toggle between the two states for real-time formatting, or address to formatting issue at the end with "tags visibility" turned back on.

This would eliminate one of the requirements of BV. It doesn't, however, address the copy/paste issue....or maybe it does?

It would not, however, solve the other issue I was going to bring up - that of easily checking links for TOC's and indices. AFAIK, clicking them in BV is the only way of (easily) checking that they are pointing to the correct place....

[BetterRed]

Originally Posted by Hendrixxxxxxxx

Wondering if it would be possible/easy/feasible to invisibilize (if that's not a word, it should be!)

What's wrong wide 'hide'

[Hendrixxxxxxxx]

Originally Posted by BetterRed

What's wrong wide 'hide'

Absolutely nothing. I've just never been a fan of simple, when complicated is available

[BetterRed]

Originally Posted by Hendrixxxxxxxx

Absolutely nothing. I've just never been a fan of simple, when complicated is available

You must be a merry can - they're renowned for there their verbosity and proclivity for prolix expression

Actually I had the same thought the other day, in a different context.

BR

[Hitch]

Originally Posted by BetterRed

You must be a merry can - they're renowned for there their verbosity and proclivity for prolix expression

Actually I had the same thought the other day, in a different context.

BR

Well, I'm not sure how you can hide the tags in the html editor, I don't mind admitting, assuming it's not a feature of the editor itself.

Juzz sayin'.

And none of this gets around the issue of the paste options.

In reading what Cliff's written, it seems to me that he and his cronies--who are clearly more sophisticated than a lot of the folks that a) come here seeking help or b) that work with companies like mine--have worked out a viable solution for their own process. I understand why he works that way, having read his full explanation. {shrug}. It works for them, and I can see why. I wouldn't work this way--but there's no reason they can't. Or shouldn't. I can also see why removing BV would, in fact, harm their method.

Hitch

[Hendrixxxxxxxx]

Originally Posted by Hitch

Well, I'm not sure how you can hide the tags in the html editor, I don't mind admitting, assuming it's not a feature of the editor itself.

Hi Hitch,


It's not (AFAIK).

I was just thinking out loud about Kevin's earlier musing

Originally Posted by KevinH

8. possibly remove BookView completely at this point since it seems to cause more issues than it is worth (no firm decision on this one way or the other)

and suggesting a potential way it could be done away with, but still retaining the ability to do the things that people do with it.....including composing directly in it.

Just throwing it out there to 1) ask the developers if making something like this (hiding html tags in code view) a feature was possible and feasible; and 2) ask the people who do use BV if this might be an alternative for them if it IS eventually done away with.

Phil

[Hitch]

Originally Posted by Hendrixxxxxxxx

Hi Hitch,


It's not (AFAIK).

I was just thinking out loud about Kevin's earlier musing and suggesting a potential way it could be done away with, but still retaining the ability to do the things that people do with it.....including composing directly in it.

Just throwing it out there to 1) ask the developers if making something like this (hiding html tags in code view) a feature was possible and feasible; and 2) ask the people who do use BV if this might be an alternative for them if it IS eventually done away with.

Phil

Hi, Phil:

I don't know--I can't speak for the guys. If it's easy, that's one thing. If it's not, it's a long way around, to address the users like Cliff. More importantly, even though it would eliminate the "distraction" issue (of using the HTML editor full-bore), it wouldn't address the paste-issue.

Personally, I think I would find it more confusing, not less. I write/type in HTML almost all the time now, between using NTPro and the backend of Joomla, and so...if my HTML tags suddenly disappeared in one or both of those, I'd constantly FORGET that it was the HTML editor, and start pasting or whatever--something that I'd normally do in the end-user view. (The front-end of the website, or whatever. Bad example, but you know what I mean.).

Just thinking aloud. If the guys want to offer that as a feature, as long as it can be ignored, doesn't matter to me. Just seems like it would be a feature that hasn't been requested, if you see what I mean.

Hitch

[CliffB]

From Hendrixxxxxxxx -

Wondering if it would be possible/easy/feasible to invisibilize (if that's not a word, it should be!) the html tags in code view (with maybe image tags excepted) - so they are still there, but invisible. Code view would look like a simple text editor while the tags are invisible.

This would get around the issue of trying to read around tags for those who compose in Sigil (maybe with automatic </p><p> tags inserted for each carriage return).

From Hitch -

In reading what Cliff's written, it seems to me that he and his cronies--who are clearly more sophisticated than a lot of the folks that a) come here seeking help or b) that work with companies like mine--have worked out a viable solution for their own process. I understand why he works that way, having read his full explanation. {shrug}. It works for them, and I can see why. I wouldn't work this way--but there's no reason they can't. Or shouldn't. I can also see why removing BV would, in fact, harm their method.

From Hitch -

I don't know--I can't speak for the guys. If it's easy, that's one thing. If it's not, it's a long way around, to address the users like Cliff. More importantly, even though it would eliminate the "distraction" issue (of using the HTML editor full-bore), it wouldn't address the paste-issue.

Yes, Book View as it is currently implemented works well for us, with some tweaking of the results occasionally in Code View. BUT, there may be more than one way to skin a cat! We understand that there are trade off's.

Joining in on the brain storming, Hendrixxxxxxxx's idea of being able to hide tags in Code View may be interesting (if this solution is viable from the perspective of the developers and saves them headaches).

On the negative side it would not be the wysiwyg rendering of the current book view which is nice. Would hiding the tags look like plain text? Or could it show Bold, Italics and Headings? Are there any editors already out there that have this type of functionality that we could evaluate and learn from?

On the positive side it seems like some of the quirky behavior exhibited by the current implementation of Book View could be eliminated. More consistent behavior would be nice.

For sure there is room to deliberate on the tradeoffs. Lose some (but not all) of the wysiwyg and distraction free goodness, but gain more consistent behavior. This is worth considering. Even though Book View works well for us it would be nice to eliminate the need to periodically clean up unintended tags in Code View. Also, I understand how non-technical users would find the behavior of Book View frustrating as it is currently implemented. This no doubt leads to some complaints.

And like Hendrixxxxxxxx said there are other issues to consider, such as retaining the current copy & paste functionality of Book View.

[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?