Suggestions for Sigil Improvements or New Features

[philja]

Originally Posted by KevinH

Yes, this round is closed.

But I really can not see changing things just to save one click for something you do once and can apply to all selected html files at the same time? Why not just create a template with your stylesheet already linked? Or use a clip if you standardize your epub layouts/structure?

I certainly do both those things but it happened a few times recently where it wasn't appropriate to use my template nor my clips. That's when it occurred to me that it seemed a bit silly to have to use a few clicks to do something that could (possibly) be made to happen automatically with a single click, just like adding a new empty file.

But, I'm not declaring an emergency.

[KevinH]

It can not be a single click any time there are multiple stylesheets to link, as order matters. The interface is fine as is.

[un_pogaz]

Okay, it probably too late for this cycle, but Sigil "do not" support Kepub.

When a try to open a .kepub file, sigil fail to load it, but if I rename it .epub, is work fine.
Since Kepub are just ePub3 under a other name, it could be handy to support them.

EndeavourOS (Arch)

[KevinH]

Sigil does support importing anything that follows the epub spec as indicated by the .epub file extension (ie. filter on the select file dialog). As you noted, simply rename it to .epub and load it.

Is there something in kepub that does not meet the epub spec?

If not, why add a different extension? What purpose does it serve?

I can add it as a recognized input file extension but that extension will be replaced by .epub upon saving in Sigil so what is the point if the file formats are identical.

Would adding .epub but not replacing the .kepub work? Something like book.kepub.epub or book_kepub.epub?

If there are minor differences, then use input and output plugins to handle them. Even if there are no differences, you can use an output plugin for saving it with any extension or extensions you want. That is what input and output pluguns were designed for.

[DiapDealer]

Kepub should be considered proprietary in my mind. Only Kobo uses it. I have no idea if it's spec compliant or not (I tend to doubt it), but I'm not on board with adding it as an extension that Sigil can handle inherently.

[un_pogaz]

Originally Posted by KevinH

Is there something in kepub that does not meet the epub spec?

If not, why add a different extension? What purpose does it serve?

Ask Kobo for that.
They created their own format derivated from the ePub and as far as I know, it is perfectly compatible with the standard. It mostly just injeting some span and js script to improve user experience on their device, but that still a ePub3 under the hood.
And their use a kepub extension probably to make it easier to identify their format when the reader trying to open them.

Sure, is not that hard to rename, but it can become tedious to always have to remember to change the extension and to restore it when trying to edit a kepub (and I'm on Linux, but on Windows that hide the extension by defautl, that can be more annoying).
Note: I don't ask a integration on the shell, just, don't raise a error "No importer for file type: kepub" when trying to open such file.

Found a Wiki entry. Yeah, apparently just a formating standard to ensure compatibility with their device. Their is a KePub Output plugin, but it take less sense to have a "KePub Intput" because it's fondamentaly a ePub.

Originally Posted by KevinH

Would adding .epub but not replacing the .kepub work? Something like book.kepub.epub or book_kepub.epub?

Hmm, that not ideal but acceptable since I mostly just open kepub to look inside and rarely to make change. And prefer "<book>.kepub.epub".

[KevinH]

Here is an interesting document to read about all of the limitations of kobo kepub and epub versus the actual epub spec. Kobo is quite a limiting format with no css page break support on their desktop ereaders and lots of issues, restrictive file naming conventions, against all use of em for margins, against use of javascript for formatting documents, etc, etc.

Kobo really needs to update its e-reading software to something using real webkit engines.

https://github.com/kobolabs/epub-spe...ster/README.md

As it stands, I think kepub would best be handled by input and output plugins in Sigil as they have real limitations and do not use epub3 landmarks/semantics or even use most of the metadata a normal epub3 would provide.

Not a format I would choose over standard epub3 just based on its long list of limitations alone.

Certainly, on the Desktop, Thorium would be a better e-reader once stripped of kobo drm.

[KevinH]

And based on this code from calibre:

https://github.com/kovidgoyal/calibr...sh/kepubify.py

There are quite a large number of quirks being accounted for including wrapping the contents of each body tag with both outer and inner divs, wrapping sentences in spans, etc, that really do not make reading and writing kepub files in Sigil directly possible.

So if this is something you plan to do, you should either convert the .kepub to normal epub3 using Calibre or write your own input and output plugins for Sigil probably using calibre code as a model for all the changes needed. Then make sure your css does not use tag selectors for div and span, since they are being injected for use by kobo.

So although you can read in a kepub into Sigil, it will be full of such junk that most people will want to clean up or remove, to actually get a clean epub3.

[un_pogaz]

Understandable.
I didn't think it would be such a strict format and yes, I don't ask to support a complet new standard. At least the subject was discussed and rename the extension will be sufficient for my needs.

[retiredbiker]

Originally Posted by KevinH

And based on this code from calibre:

https://github.com/kovidgoyal/calibr...sh/kepubify.py

There are quite a large number of quirks being accounted for including wrapping the contents of each body tag with both outer and inner divs, wrapping sentences in spans, etc, that really do not make reading and writing kepub files in Sigil directly possible.

So if this is something you plan to do, you should either convert the .kepub to normal epub3 using Calibre or write your own input and output plugins for Sigil probably using calibre code as a model for all the changes needed. Then make sure your css does not use tag selectors for div and span, since they are being injected for use by kobo.

So although you can read in a kepub into Sigil, it will be full of such junk that most people will want to clean up or remove, to actually get a clean epub3.

I think it is quite clean to keep all my books as plain epub, and let Calibre convert to kepub as it sends a book to my Kobo. All the books show up in the Kobo as <book>.kepub.epub. I never bring one back the other way.

I did try, just for fun, to edit some ".kepub.epub" books once but it is a migraine just waiting for you. I agree with the idea of converting with Calibre back to epub. I don't think I've never run across a book that had a filename of just plain .kepub.

I can't se any point in storing .kepub.epub files on my machine. If I buy a Kobo book on the reader, I can still go to the site and download an epub. So far, at least.

[RbnJrg]

Originally Posted by KevinH

Kobo really needs to update its e-reading software to something using real webkit engines.

Kobo for Android has a very modern rendering engine (practically supports all epub3 except MathML). The problem is in its physical device; it leaves much to be desired there.

[DNSB]

Originally Posted by DiapDealer

Kepub should be considered proprietary in my mind. Only Kobo uses it. I have no idea if it's spec compliant or not (I tend to doubt it), but I'm not on board with adding it as an extension that Sigil can handle inherently.

Kepub is completely spec compliant with ePub. The main difference is the addition of spans that are used for location for annotations/bookmarks ( sample would be <span class="koboSpan" id="kobo.4.1">In porttitor. </span> ). Since a Kobo ereader looks for a .kepub.epub extension to indicate a kepub, on my computer, it is handled as an .epub file. A while back, it was common for ePub3 Kobo ebooks to have javascript but I've seen that less over the last few years.

The only place where I used to find .kepub files was in my calibre library where I converted the occasional ePub that benefited from using the Kobo renderer and stored it as filename.kepub to which calibre appended .epub when sending to device. Since calibre now allows converting to kepub on the fly, I now just have a column that decides which format to send.

All this being said, I see no good reason for trying to handle kepub files as separate from ePub files.

[DNSB]

Originally Posted by KevinH

Kobo really needs to update its e-reading software to something using real webkit engines.

In my testing of the current Kobo renderer which is based on the Readium/webkit code, it seems to be very close to Thorium on Linux in terms of spec coverage and limitations. As for the website, I'm not certain that much of the information on it has been updated since Kobo started using the ACCESS NetFront BookReader v1.0 EPUB Edition to allow handling ePub3 and Japanese typography which was about 13 years ago.

While the latest Kobo code in it's V5.xxx firmware uses Kobo's renderer as the default renderer as seen in Tolino devices and Kobo devices with the EU acessibility code, Kobo still supports RMSDK for it's ability to handle Adobe's ADEPT DRM.

Originally Posted by KevinH

Certainly, on the Desktop, Thorium would be a better e-reader once stripped of kobo drm.

See above. As an aside, close to 87% of my purchases this year from Kobo have arrived without DRM. Unlike a certain other ebook vendor, Kobo only adds DRM on request from the publisher.

[un_pogaz]

Even if Kepub is completely spec compliant with ePub, the real issue here is that if you make changes in Sigil, Sigil cannot guarantee that the saved file will be compliant with the strict Kepub formating.
Therefore, it is safer to not allow users to modify a kepub to prevent to broken it.
And I fully understand that Kepub support is more the ressort of in/out plugins.

Else, after thinking about it, the fact that Sigil check the file extension when try to open a file is still quite annoying.
I therefore suggest adding a environement variable that toggle this behavior SIGIL_DISABLE_EXTENSION_CHECK.
If toggle, Sigil will try to open any given file (like in command line), regardless of its extension, and will save the edited file ate the exact same path (so without extension alteration). The target file might not even have an extension that it would be okay.
Since it a environement variable, it a advanced option that only advanced user would use, and toggle it would imply that your on own to open non epub file.

[KevinH]

No, I have no interest in adding or modifying Sigil's ImportEPUB.cpp code to handle files without extensions, and all the possible crap that would need to be fixed if the file selected does not meet the epub standard (i.e. no nav, no spine, broken spine without xhtml included in it, missing manifest items, missing metadata, etc).

File extensions are integral to Sigil and used everyplace, especially in the manifest when bad software does not specify media-types.

Again, use an input plugin if you want general or extensionless files to be loaded by Sigil but be prepared to write a bunch of python code to fix things up to create a reasonable .epub file.