New Features or Improvements post Sigil 2.8.1

[3333]

Originally Posted by KevinH

@3333

Thank you for the idea and implementation as it is a very nice feature in general but it is not for Sigil at this time. Sigil has existing methods to view images (double-click, or via pop-up menu View Image) and select images from a list with user controllable thumbnails, neither of which have any long-term memory footprint implications, and neither cause inadvertent visual distractions for some users.

If it at all helps, our users did test your proposed changes and have a few suggestions you may want to incorporate in your own implementation:

- on MacOS arm64 increase the delay to 300ms to better approximate the macOS normal delay and prevent unwanted flashing of images as the cursor is moved back and forth over the images in BookBrowser. That flashing can be dangerous and trigger some individuals.

- small images below the thumbnail size are pixelated when shown in thumbnail form that is larger, so you may want to not scale images whose normal size is smaller than the thumbnail size.

- some users preferred a user setable thumbnail size as they found the thumbnail either too large or too small.

- add a way for the user to completely disable the feature if they find the thumbnails distracting as many did.

Hope something here helps! Thanks again for your suggestion.

Thank you, KevinH, and thank you to everyone who took the time to test the implementation and share feedback.

I have learned quite a lot from the discussions here over the past few days, especially about how you evaluate the balance between a feature itself and the additional code, memory usage, complexity, and long-term maintenance that comes with it.

We will keep this feature in Sigil-Enhanced and continue improving it based on the feedback from this discussion and the testing results.

Thank you again for taking the time to test it and for pointing out these issues and suggestions. We will keep working to improve both the project and the quality of the contributions we prepare in the future.

[KevinH]

Sigil has gotten so large (installed with internal Qt and Python 3.14, it takes close to 500 meg on disk) with features that no one really uses over the last 15 years in my opinion. And unfortunately very few users are aware of even a fraction of them. Adding plugins has helped. As has adding checkpoints, diff comparison, a dry run mode for a user to test replace-all safely before applying it, expanded clips to 60, etc.

So now we are down to adding features only when they help the majority of users and only if it can not be done in a plugin.

Harsh rules. But truly needed at this point. So new features will still be added but they need to be justified along all the dimensions you mentioned.

Thanks again for all the help you have already provided.

[byword]

When making books, I often have to insert different Special Characters that aren't on the keyboard.
Things like ā, ⓪ (I use circled characters a ton), ©, Hebrew for humanities books, or math symbols for science books.
When you start working with accessibility, you end up having to hunt down a ton of special characters. You actually have to tell the difference between all of these: ─, ━, –, —, and ―.

Every time I need one, I search the internet and paste it in, but the "Insert Special Character" feature should fix this.

Calibre's Special Character tool is pretty much perfect for inserting codes.
Is there any way we could get something like that in Sigil's Special Character feature?

[KevinH]

There is already an Insert Special Character dialog for Sigil. What exactly is not included that you are missing? Please be specific.

[byword]

Originally Posted by KevinH

There is already an Insert Special Character dialog for Sigil. What exactly is not included that you are missing? Please be specific.

Please take a look at this post. I have explained it in detail here.

[KevinH]

Originally Posted by byword

Please take a look at this post. I have explained it in detail here.

As it stands it is way overkill for almost all users as it includes all symbols from unicode including thise from dead languages and symbols/glyphs most fonts do not support. Furthermore and more importantly, it duplicates things that are already part of most OS's (MacOS already has a character generator built in as do many Linux boxes) and duplicates the functionality of many unicode websites that do the same thing.

So it is really going to have to be greatly pared down in some way if it is going to be acceptable to Sigil.

[isaacbh]

The ability to pin tabs. Was it suggested before? I return often to the css and opf tabs, and it would be nice if they wouldn't get lost with all the other html tabs. Pinned tabs could have an indicator or a different color.

[KevinH]

Just double click on the file you want in BookBrowser and if its Tab is already open it will bring it to the front. And if not, it creates a new Tab.

[Doitsu]

I have two minor cosmetic suggestions for the next Sigil version:

1. EPUBCheck 5.4.0 has deprecated EPUB2-style <meta> attributes in epub3 books.
This includes the Sigil version number information:

<meta name="Sigil version" content="2.8.1" />

which will be flagged as:

USAGE(OBS-001): Usage of the OPF 2 "meta" element is outdated.

I'd recommend the following change, which passes EPUBCheck 5.4.0

<meta property="schema:softwareVersion">2.8.1</meta>

or

<meta property="schema:softwareVersion">Sigil 2.8.1</meta>

Reference: softwareVersion / reserved prefixes

EPUBCheck 5.4.0 also doesn't like the cover image metadata entry in epub3 books.

<meta name="cover" content="image.jpg"/>

I'd recommend removing it in epub3 books, since, AFAIK, Amazon and Kobo will use the properties="cover-image" manifest attribute.

2. EPUBCheck 5.4.0 no longer requires the xlink prefix in epub3 SVG cover images generated by the Add Cover tool.

it'll flag:

<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 1200 1000" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image width="1200" height="1000" xlink:href="../Images/image.jpg"/>
</svg>

as:

USAGE(HTM_062): SVG "xlink:href" attribute is deprecated; an "href" attribute should be used instead.

Apparently, they want this version now:

<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 1200 1000" width="100%" >
<image width="1200" height="1000" href="../Images/image.jpg"/>
</svg>

[KevinH]

Good ideas, but these are just usage. None of them will cause a book to be rejected.

And making epub3 book work in epub2 only readers would be broken by those changes to the cover image meta.

Also xlink is a valid xml prefix long recognized in xhtml and html. Deprecating it is not a good idea. And it might break svg covers in epub2 ebooks as well.

I personally think many changes in epubcheck 5.4.0 were accepted when they thought they would allow pure html but the public push back made them change their mind but the changes in epubcheck 5.4.0 remained.

On top of that, using bare text inside the body tag is the biggest mistake epub developers can make for accessibility, styling, etc yet they will not even create a usage message for it.

Then they add image formats that are not widely supported in most shipping browsers as **base level** image media types for no good reason. Again, I bet for prep for adding html that never happened.

None of these changes make sense and now conflict with the epub 3.0 and 3.1 spec that clearly said that all old meta tags should be ignored (not should be marked as a usage error!). That should force a 4.0 version alone, as it is a spec breaking change.

If I remove the old meta for cover images in epub3, then creating an epub3 that works correctly on an epub2 only reader will no longer be possible, and all for just a "usage" message?

I will have to think about the best way to handle these, especially for epub3 backwards compatibility for epub2 e-readers.

[KevinH]

Update, I can easily fix the Sigil metadata for epub3, as that should have has no backwards compatibility issues.

I will have to search the Update Link code in Sigil (impacts renames, and restructuring to Sigil standard form) as it stands xlink is required for svg image links. This will take some work. And xlink is still needed under epub2 as far as I know.

As for old meta cover images, I am in a quandary. Maybe we add a Sigil User's pref to control whether they are added to epub3 or not as making epub3 backwards compatible for older e-reader seems much more important that a "usage" message. But some people will be overly pedantic even over epubcheck Usage messages, so some change will be needed.

Just wish epubcheck devs would stop making so many bad decisions, especially when they will not add usage for raw text in the body but then turn it on for things that actually violate their own epub 3.0, 3.01, 3.1, 3.2, and 3.3 specs, and worse yet add base image mediatypes that will never be adopted by current or older epub2 or epub3 e-readers - which means epub dev would be crazy to ever use them. It is clear they just do not understand the publishing industry which favours stability.

[JSWolf]

I just tested the new SVG code and it breaks the older ADE/RMSDK. So it will break on Kobo's and other Readers that use an older version of RMSDK. I canto say how ADE 4.5 will handle this. Older software will break for a rather stupid unnecessary change.

I cannot say if what current software will work with this stupid change. I've tested QT works and Thorium. They both work.

[Doitsu]

Originally Posted by KevinH

I will have to search the Update Link code in Sigil (impacts renames, and restructuring to Sigil standard form) as it stands xlink is required for svg image links. This will take some work. And xlink is still needed under epub2 as far as I know.

I've just double-checked this. All you need to do to make the USAGE message go away is add an additional href attribute (like lang and xml:lang in XHTML.

E.g.

<svg xmlns="http://www.w3.org/2000/svg" height="100%" preserveAspectRatio="xMidYMid meet" version="1.1" viewBox="0 0 800 1111" width="100%" xmlns:xlink="http://www.w3.org/1999/xlink">
<image width="800" height="1111" href="../Images/cover.jpg" xlink:href="../Images/cover.jpg"/>
</svg>

This should be a relatively easy fix.

[elibrarian]

Originally Posted by JSWolf

I just tested the new SVG code and it breaks the older ADE/RMSDK. So it will break on Kobo's and other Readers that use an older version of RMSDK. I canto say how ADE 4.5 will handle this. Older software will break for a rather stupid unnecessary change.

I cannot say if what current software will work with this stupid change. I've tested QT works and Thorium. They both work.

ADE 4.5 seems to have no problem with it. But Readest v. 0.12.8 / Based on Edge 153 don't like it, it seems.

IIRC the xlink:-thing is deprecated, but isn't it only in SVG 2, not SVG 1.1 that's used in epubs? If so, I should think the usage-recommendation in epubcheck is an error. Personally, I won't follow it any time soon, if ever.

Regards,

Kim

[JSWolf]

Originally Posted by elibrarian

ADE 4.5 seems to have no problem with it. But Readest v. 0.12.8 / Based on Edge 153 don't like it, it seems.

IIRC the xlink:-thing is deprecated, but isn't it only in SVG 2, not SVG 1.1 that's used in epubs? If so, I should think the usage-recommendation in epubcheck is an error. Personally, I won't follow it any time soon, if ever.

Regards,

Kim

If any covers are using an SVG wrapper and the ePub has to pass epubcheck, then it's going to break backwards comparability.