What Features or Tools does Sigil Still Need Yet?

[KevinH]

Unfortunately, the nav is being completely rebuilt each time from scratch and any added attributes are lost. That said, any time we add an epub-type toc attribute we can add in the matching aria roll attribute as well. It can not hurt!

As for default selections for editing when format tools are used when no text is selected, I will look into that. That should be doable.

I personally am not a fan of autocorrect or autocomplete. When writing longer things I typically speed things up by using my own unique abbreviations for longer or often used words and then doing a find and replace for each abbreviation. But this is typically done in a Word Processor long before loading it into Sigil.

So let's hear what others are think about that feature request.

Thanks!

Originally Posted by elibrarian

Headers (H1-H6) will always be a full line. So why not make the CTRL + 1 etc. insert <h1>-</h1> tags around the line, in which the cursor is placed, if (and only if) no text is selected?

Almost the same goes for bold, italics etc. - if no text is selected, the ctrl + b (e.g.) could surround the word where the cursor is placed.

(I have made something like it in most of my tekst/html-editors using macros or AutoHotKey, and you'll be amazed how many mouse moves and time it saves!)

Also, how about an autocorrect function with the ability to use personal and exchangeable word lists (like the one in Atlantis, but with regexes)?

And then one small gripe: When I regenerate a TOC, Sigil will preserve the header and the "<nav epub:type='toc' id='toc'>", but removes "role='doc-toc'". It is of course a small thing to re-insert (I always run ACE as one of the last things before publishing my books, and it will tell me if I forget).

Regards,

Kim

[elibrarian]

Originally Posted by KevinH

I personally am not a fan of autocorrect or autocomplete. When writing longer things I typically speed things up by using my own unique abbreviations for longer or often used words and then doing a find and replace for each abbreviation. But this is typically done in a Word Processor long before loading it into Sigil.

I see that I've not been totally clear on what I suggest - I am not that great a fan of autocorrect myself, and habitually turn it off in Word etc. What I'm after is the part of the Atlantis autocorrect function that allows to load a personal/customised list of corrections and run it upon a whole text, which is extremely useful for correcting OCR'ed texts, especially from blackletter prints, where even Abbyy and gImageReader makes the same errors time and time again.

Hope this will clarify my meaning.

Regards,

Kim

[KevinH]

Sounds like a good idea for a plugin.

In fact there are already plugins that try to do things like this for common scanner mistakes. I am not sure if they are word list driven or not.

Obviously this list would need to be language specific.
Would this word list of find and replaces be book specific or reasonably static?

Could it be autogenerated from spellcheck and suggestion output?

Let's see what other people think, especially plugin devs.

Originally Posted by elibrarian

I see that I've not been totally clear on what I suggest - I am not that great a fan of autocorrect myself, and habitually turn it off in Word etc. What I'm after is the part of the Atlantis autocorrect function that allows to load a personal/customised list of corrections and run it upon a whole text, which is extremely useful for correcting OCR'ed texts, especially from blackletter prints, where even Abbyy and gImageReader makes the same errors time and time again.

Hope this will clarify my meaning.

Regards,

Kim

[DiapDealer]

I like the table-based metadata editor more, as well. But I also understand (and agree with) the reasons it is the way it is now. It's just a bit unfortunate that the metadata editor is a bit of a catch-22 in its current state. It offers a way to edit metadata in a wysiwyg manner, but using it effectively means that a fairly thorough understanding of metadata specifications and their various hierarchies is sort of a pre-requisite. And having a fairly thorough understanding of metadata specifications and their various hierarchies can mean that manually editing the opf to add metadata might actually be simpler.

But the bottom line for me is that I don't think there's a solution for a wysiwyg metadata editor for epub3 that would appeal to those already knowledgeable and would also be intuitive enough for a novice to navigate.

In other words: the easier it is, the less it can do; and the more it can do, the less useful it becomes to those who understand its use. *shrug*

That's not meant to dismiss the suggestion at all. But then I don't use the new metadata editor any more than (or less) than I did the previous one.

[Doitsu]

@KevinH

For reference purposes, here's a screenshot of the Atlantis WP Autocorrect dialog.

[elibrarian]

Originally Posted by KevinH

Obviously this list would need to be language specific.
Would this word list of find and replaces be book specific or reasonably static?

The way Atlantis has done it (and some other software of similar intention) is by lists/text files with word pairs. The lists are pure text, and interchangeable, so they are static, but you can have as many as you want for different types of books or languages, and load whichever you deem most useful for the actual purpose.

Perhaps a better example might be wReplace ( http://www.sharktime.com/en_wReplace.html ) - it's rather old and haven't seen an update for many years, but still works.

Originally Posted by KevinH

Could it be autogenerated from spellcheck and suggestion output?

Probably could. I have build mine from word frequency lists using a wordprocessor and a spreadsheet.

Regards,

Kim

[KevinH]

Based on the images and discussion above ... something like an AutoReplace tool or plugin that allows you to load and save a text file. The text file would be pipe delimited one entry per line with what to find first then a "|" character then the replacement text followed by a new line (or cr/lf for Windows).

No wild cards or placeholders would be allowed in the list. (are placeholders and wildcard allowed in Atlantis?) The find text and replacements would be *whole* word only.

All text files would be utf-8 encoded.

The interface once you selected and loaded a file would show you the loaded information in two columns, allowing a user to edit/tweak either column before doing the replacement.

Then there would be a "Do It" button, that when pushed would automatically do all of the replacements but only in the text not in tags across selected xhtml files (or all xhtml files).

It would report the total number of replacements per file.

That sounds very very doable, although it may be better as a plugin..

Please correct or adapt the above (anyone who is familiar with tools like this) as needed to refine exactly what is being suggested.

Thanks!

[KevinH]

What if we did go to a two-stage approach with a scrolling form style interface with pulldowns with just the most used and basic set of metadata on the first stage and an advanced button to load the current metadata editor, updated with any changes on the first form.

If we did that, then what information should appear on the first form (it could even be an html form that is create on the fly and loaded in a Preview-like tool).

book main title
book secondary title
book series number
book series title
primary language pulldown
secondary language pulldown
author1 with file-as
author2 with file-as
author3 with file-as
contributor1 with associated role pulldown
contributor2 with associated role pulldown
contributor3 with associated role pulldown
subject
keywords
description bigger box supporting html markup
identifier1 with pull down for identification type
identifier2 with pull down for identification type
publication date

and what else?

How about that approach?

Originally Posted by DiapDealer

I like the table-based metadata editor more, as well. But I also understand (and agree with) the reasons it is the way it is now. It's just a bit unfortunate that the metadata editor is a bit of a catch-22 in its current state. It offers a way to edit metadata in a wysiwyg manner, but using it effectively means that a fairly thorough understanding of metadata specifications and their various hierarchies is sort of a pre-requisite. And having a fairly thorough understanding of metadata specifications and their various hierarchies can mean that manually editing the opf to add metadata might actually be simpler.

But the bottom line for me is that I don't think there's a solution for a wysiwyg metadata editor for epub3 that would appeal to those already knowledgeable and would also be intuitive enough for a novice to navigate.

In other words: the easier it is, the less it can do; and the more it can do, the less useful it becomes to those who understand its use. *shrug*

That's not meant to dismiss the suggestion at all. But then I don't use the new metadata editor any more than (or less) than I did the previous one.

[elibrarian]

Originally Posted by KevinH

No wild cards or placeholders would be allowed in the list. (are placeholders and wildcard allowed in Atlantis?) The find text and replacements would be *whole* word only.

Placeholders and wildcards are not allowed in Atlantis (which is my main gripe withe the Atlantis implementation). Given it is made as a plugin, wouldn't Python's regex engine be able to handle something in that direction?

(I would have no objections to a plugin - would the plugin implementation be significant slower than a C++ implementation in the Sigil core if working with big files/many replacements?)

Regards,

Kim

[Doitsu]

Originally Posted by KevinH

Based on the images and discussion above ... something like an AutoReplace tool or plugin that allows you to load and save a text file. The text file would be pipe delimited one entry per line with what to find first then a "|" character then the replacement text followed by a new line (or cr/lf for Windows).

Since most user probably maintain such list with a spreadsheet app, I'd recommend that the input files should be two-column .csv or tab-delimited files, because both can be easily exported.

Originally Posted by KevinH

All text files would be utf-8 encoded.

This is a good idea, because some Windows apps still save .csv files as ANSI/CP1252 files, but most can save UTF-8 files.

Originally Posted by KevinH

That sounds very very doable, although it may be better as a plugin.

Agreed. I actually might write one over the Christmas break, if enough users are interested and KevinH isn't interested in writing it.

Originally Posted by elibrarian

Given it is made as a plugin, wouldn't Python's regex engine be able to handle something in that direction?

Python actually has two regex engines (re and regex) and one of them even has limited support for fuzzy searches.

Originally Posted by elibrarian

(I would have no objections to a plugin - would the plugin implementation be significant slower than a C++ implementation in the Sigil core if working with big files/many replacements?)

That depends on the implementation and the number of entries in the list. A C++ implementation would definitely be faster, but a pure Python solution shouldn't be that much slower, especially, if the list isn't too long.

[KevinH]

The issues with regular expressions would be the need to capture and replace wildcard text and then to get users to properly regex escape any entries that use any regex special chars but do not want regex including (, ), *, !, ., ?.

Also since fully automated, regex could easily lead to unexpected matches and replacements. It is probably better used inside Find and Replace where you can say "no", just for safety sake.

Speed of python should not be an issue as this need not be done in real time, and is most likely once or twice perhaps with different lists.

Originally Posted by elibrarian

Placeholders and wildcards are not allowed in Atlantis (which is my main gripe withe the Atlantis implementation). Given it is made as a plugin, wouldn't Python's regex engine be able to handle something in that direction?

(I would have no objections to a plugin - would the plugin implementation be significant slower than a C++ implementation in the Sigil core if working with big files/many replacements?)

Regards,

Kim

[KevinH]

And Doitsu, yes we could use commas or better yet tabs as delimiters. A pulldown to select delimiter char might also be a good idea as lists can then come from different sources.

[Doitsu]

Originally Posted by KevinH

And Doitsu, yes we could use commas or better yet tabs as delimiters. A pulldown to select delimiter char might also be a good idea as lists can then come from different sources.

On second thought, there actually is no need to create a brand-new new plugin, because users already can create a Saved Search groups.
All that's missing is an import filter for comma/tab-delimited files.

How about simply adding .csv and .txt files as file types to the Import Search Entries dialog box? (.txt would be for tab-delimited files)

[KevinH]

What format does it currently import and export?

I had no idea this feature even existed in Sigil!

[Doitsu]

Originally Posted by KevinH

What format does it currently import and export?

AFAIK, users can only import and export Saved Searches .ini files.