Sigil’s Future Direction (Post 0.4.x)

[charleski]

Originally Posted by crutledge

FYI. No big thing.

About half the time a section will open in SPLIT VIEW.

When you switch to an xhtml flow within the book that isn't already open Sigil will use the same view that was last used. But some elements (images, the opf and ncx files) don't have the option to use Book or Code views so Sigil doesn't know what your preference is when you switch from one of those to a new xhtml flow and it defaults to Split view as a 'best-of-both-worlds' option. This is one thing that can go in the preferences dialog when we get round to it.

[mrmikel]

Re image removal, kiwidude has the right idea with multi select. It was the first thing I tried to do and failed at. I never have reused the same image so far, so it didn't even occur to me. But I can see how automatic deletion could create a big problem for those who use a repetitive separator graphic etc.

[cybmole]

one thing that I'd find useful, when tidying:

detect, with an option to delete - those styles in the stylesheet which are not used anywhere in the book.

takes ages to do this manually a each candidate needs a find /count operation run across all files

I'm thinking of a "styles in use" summary which counts number of times each style is used & outputs a list or a table of results

meanwhile if anyone knows an easy way to detect all un-used styles, please tell

[kiwidude]

@cybmole - perhaps when the plugin architecture is in place this sounds a good candidate. I too would love it. The responses I have seen on this previously is "it does not matter about having unused styles lying around". Which personally I disagree with - because when it comes time to make style changes to the document your maintenance job that much harder.

It would be nice to have the reverse as well - the ability to delete styles and have all usages of that style removed from the document. A good example is OCR conversions which can be peppered with dozens if not hundreds of styles that do pointless things like "letter-spacing" etc. It would be nice to just be able to delete all those styles from the css file, and then run a function that removes all orphaned styles from the rest of the doc.

[user_none]

Auto remove unmanifested files, remove unused CSS, remove CSS references that don't exist, and various levels of CSS normalization are all plugin candidates. Do remember that the plugin interface is targeted at 0.6. So it will be some time before this becomes reality.

[theducks]

Originally Posted by kiwidude

@cybmole - perhaps when the plugin architecture is in place this sounds a good candidate. I too would love it. The responses I have seen on this previously is "it does not matter about having unused styles lying around". Which personally I disagree with - because when it comes time to make style changes to the document your maintenance job that much harder.

It would be nice to have the reverse as well - the ability to delete styles and have all usages of that style removed from the document. A good example is OCR conversions which can be peppered with dozens if not hundreds of styles that do pointless things like "letter-spacing" etc. It would be nice to just be able to delete all those styles from the css file, and then run a function that removes all orphaned styles from the rest of the doc.

I would love a Where used report, even if it only reported the file name(s) it was found used within.

[Serpentine]

I'm not exactly how to describe what I'm thinking of - but it's something I think would be quite handy for doing a quick check on formatting and such. This could most likely already be done with some auto-magical CSS, but having it as a universal function would be quite nice and less laborious.

The 'book view' would have a background colour for each tag type (and perhaps class, if you were to be fancy). So paragraphs show up with a light blue background, spans within them show up with a light green background, allowing you to spot pointless tags (and as such get around to getting rid of their redundant CSS at the same time).

I have a burning hatred for the way some MSO exported epubs have nested spans as whole paragraphs, each having their own class etc. While regex fixes that quickly, there are a number of other such similar things which I end up finding later on.

It works well in my head at least! No doubt some shortcoming elsewhere

[JSWolf]

Originally Posted by kiwidude

What would perhaps help in this regard would be two things:

(1) Multi-select in the tree to allow deleting multiple items at once

Please implement this like now. I really need it. With all these Omnibus editions coming out, I prefer to split the books and doing it file by file is not nice.

[EowynCarter]

Originally Posted by JSWolf

Please implement this like now. I really need it. With all these Omnibus editions coming out, I prefer to split the books and doing it file by file is not nice.

True.
I foudd the best way for this is to un-zip the ePub. Then, create a new book and add the relevant html files.
Sigil will also get the images / css that are linked.

[Danger]

Originally Posted by user_none

remove unused CSS, remove CSS references that don't exist

Those are two options that would be great to see implemented as a plugin or even into Sigil

[Hooliator]

It would be really nice if I could open files by using the Enter key when the file name is high-lighted in the Book Browser.

[crutledge]

I put illustrations into the TOC with the following code:

<h3 id="fland001" title="ILLUS: SHOUTNIGHT THE OWL AND FLUTETHROAT THE BLACKBIRD"><img alt="" src=
  "Featherland_files/fland001.jpg" /></h3>

This shows up inline in the TOC indented beneath the appropriate heading.

Some time ago a List of Illustrations was discussed for Sigil.

Is there a definition for a seperate LOI in the ePub spec and how would it be handled and displayed?

[LGN]

About de-emphasising the BookView: Often someone else proofreads the ePUBs and any corrections/changes/edits to the textual content are made and send back to me for final polish. Having code view presented to non-technical people who do use Sigil to do small edits might make it harder. We technical people can find the code view, but for the non-technical users who need to see the result and not the code, a valid use, and make simple edits the BookView is the most important way they use Sigil.

I hope the dev's keep that in mind also because a 'power-user' doens't always stand on their own.

[Zeypxi]

Hi, epub3 is out, John, do you think that the next version 0.5 will have a support for the new recommendations? If so, have you already thought of the main changes in Sigil? like for example save as en epub2 file option for compatibility issues? Will you keep Tidy as part of Sigil?

idpf.org/epub3-a-final-recommendation

[user_none]

Originally Posted by Zeypxi

Hi, epub3 is out, John, do you think that the next version 0.5 will have a support for the new recommendations?

No. EPUB 3 won't be supported for quote some time. 0.6 or 0.7 possibly.