kepubify v3: A fast, standalone EPUB to KEPUB converter (plus covergen/seriesmeta)

[rashkae]

Originally Posted by JSWolf

Given that Panda AV also thinks Calibre is a problem, I would dump Panda AV. It's not worth bothering with given that it doesn't work properly.

I would prefer an AV with more false positives than the other around... but at the end of the day, you have to make a judgement, (whether your AV warns you or not,), and telling the AV to STFU is something that has to be one on your end, not by Kepubify, Calibre, or whatever software.

[geek1011]

Originally Posted by toancv

I am using the exe file on Windows 10. I use drag and drop method for ease. But the new file name always has "comverted". Can I remove this "word" for every time converting? Thanks!

Yes. Just add the --inplace option. Make a batch file with the following text: @kepubify-windows-64bit.exe --inplace %*

[toancv]

Originally Posted by geek1011

Yes. Just add the --inplace option. Make a batch file with the following text: @kepubify-windows-64bit.exe --inplace %*

Thanks! It works.

[ilovejedd]

Originally Posted by toancv

Where exactly the "Unblock" option. I could find nowhere. I am Windows 10. Thanks!

As mentioned, right-click on the file -> Properties

The option goes away after unblocking. Sometimes, the flag is never set depending on how the file was downloaded and zone/security settings. Iirc, Firefox downloads don't get flagged.

[rtiangha]

OK, I've got a question about this change:

- Span adding has been refactored and improved to better match Kobo. This means that the numbering of spans may be different if you reconvert a book.

Back in 2016, jackie_w discovered that the reason why optimizeLegibility when enabled (either by patch or ebook css modification) produces weird spacing in justified text is because of span fragmentation; basically, it appears that the Kobo algorithm is aggressive and sometimes breaks up sentences into multiple spans when one span for the whole thing would probably be enough and posted some screenshots highlighting the difference (the one with less span fragmentation looks better).

If kepubify 3.0 better mimics Kobo's way of doing things, will that make the span fragmentation problem better or worse (I don't know how kepubify 2.0 did it instead)? Is there a way for a future version of kepubify to do a better job in reducing span fragmentation even if it means not following Kobo's conventions in applying spans during conversion (maybe by following jackie_w's hacked KTE algorithm)?

[rtiangha]

And one more question: I basically want to enable the "Improve legibility" and "Use real small capitals" tips from this page.

If the css argument can only be a single string, then did I do this right in my .bat file (I basically just removed all newlines)?

@kepubify-windows-32bit.exe --verbose --smarten-punctuation --fullscreen-reading-fixes --inplace --css "body {font-kerning: normal; font-variant: common-ligatures oldstyle-nums proportional-nums; font-feature-settings: "kern", "liga", "clig", "onum", "pnum";} h1, h2, h3 {font-variant: common-ligatures lining-nums proportional-nums; font-feature-settings: "kern", "liga", "clig", "lnum", "pnum";} table {font-variant-numeric: lining-nums tabular-nums; font-feature-settings: "kern", "lnum", "tnum";} code {font-variant: no-common-ligatures lining-nums; font-feature-settings: "kern" 0, "liga" 0, "clig" 0, "lnum";} .fraction {font-variant-numeric: diagonal-fractions; font-feature-settings: "frac";} element {font-variant: small-caps;} @supports not (font-variant-caps: small-caps) {element {font-variant: normal; font-feature-settings: "smcp", "onum", "pnum";}} @supports (font-variant-caps: small-caps) {element {font-variant: normal; font-variant-caps: small-caps;}}" %*

kepubify executes properly, but I have no idea if the above works and I can't seem to find the code in the kepub's css.

Edit: Ah, it's embedded in the html instead. But I still don't know if I did it right. This is what it makes inside the head tags using all of my options:

<style type="text/css" class="kobostylehacks">div#book-inner { margin-top: 0; margin-bottom: 0;}</style><style type="text/css" class="kepubify-extracss">body {font-kerning: normal; font-variant: common-ligatures oldstyle-nums proportional-nums; font-feature-settings: kern, liga, clig, onum, pnum;} h1, h2, h3 {font-variant: common-ligatures lining-nums proportional-nums; font-feature-settings: kern, liga, clig, lnum, pnum;} table {font-variant-numeric: lining-nums tabular-nums; font-feature-settings: kern, lnum, tnum;} code {font-variant: no-common-ligatures lining-nums; font-feature-settings: kern 0, liga 0, clig 0, lnum;} .fraction {font-variant-numeric: diagonal-fractions; font-feature-settings: frac;} element {font-variant: small-caps;} @supports not (font-variant-caps: small-caps) {element {font-variant: normal; font-feature-settings: smcp, onum, pnum;}} @supports (font-variant-caps: small-caps) {element {font-variant: normal; font-variant-caps: small-caps;}}</style><style type="text/css" class="kepubify-fullscreenfixes">body {
    margin: 0 !important;
    padding: 0 !important;
}

body>div {
    padding-left: 0.2em !important;
    padding-right: 0.2em !important;
}</style>

Will that actually work? Sorry for the dumb question; I'm weak on how css works.

[JSWolf]

@geek1011 Is there an option for kepubify to turn on kerning? If not, can such be added?

[rtiangha]

Originally Posted by JSWolf

@geek1011 Is there an option for kepubify to turn on kerning? If not, can such be added?

Why not just have kepubify modify the css? Either by enabling the optimizeLegibility property of text-settings (via css or patch; apparently, that setting reads kern data even if the font doesn't have an old school kern table) or by enabling the "kern" property of font-feature-settings (or is it -webkit-font-feature-settings; I'm not sure)?

[geek1011]

Originally Posted by rtiangha

OK, I've got a question about this change:

If kepubify 3.0 better mimics Kobo's way of doing things, will that make the span fragmentation problem better or worse (I don't know how kepubify 2.0 did it instead)? Is there a way for a future version of kepubify to do a better job in reducing span fragmentation even if it means not following Kobo's conventions in applying spans during conversion (maybe by following jackie_w's hacked KTE algorithm)?

Well, a few of the main changes cause there to be less spans. For one, kepubify doesn't split in colons anymore, as I didn't find any recent books which did it, but I found ones which didn't. Another is that kepubify doesn't swallow whitespace under various conditions anymore. It won't eat or wrap whitespace directly under the body tag (it used to eat it), and it won't eat multiple spaces between sentences or when it is all that is in a node. Also, it won't break up punctuation without a space after it (this causes a bunch of layout issues, and doesn't even match Kobo, see the test cases). In addition, it won't wrap whitespace sitting by itself, neither will it increase the paragraph counter for it (see the test cases). A few other improvements to the span code include not incrementing the counters if no spans were added to a node due to an exception, and wrapping the entire IMG tag rather than just putting a span before it. Kepubify will also wrap text in heading tags too.

Quite a few of these improvements aren't in the Calibre extension, and I think they should be implemented (e.g. whitespace behavior, not splitting on colons).

Although, one behavior I haven't managed to replicate is how Kobo sometimes also increments the paragraph counter on span and a tags. This only causes an offset of one or two under a few books, so I don't consider it a big issue.

You can test how kepubify differs from an official book (or even from a calibre-converted book) by running kobotest (it's in the repo) with an xhtml file with spans as stdin.

P.S. Read the test suite in the kepubify code, it will explain a bunch of this with examples.

[geek1011]

Originally Posted by rtiangha

And one more question: I basically want to enable the "Improve legibility" and "Use real small capitals" tips from this page.

If the css argument can only be a single string, then did I do this right in my .bat file (I basically just removed all newlines)?

@kepubify-windows-32bit.exe --verbose --smarten-punctuation --fullscreen-reading-fixes --inplace --css "body {font-kerning: normal; font-variant: common-ligatures oldstyle-nums proportional-nums; font-feature-settings: "kern", "liga", "clig", "onum", "pnum";} h1, h2, h3 {font-variant: common-ligatures lining-nums proportional-nums; font-feature-settings: "kern", "liga", "clig", "lnum", "pnum";} table {font-variant-numeric: lining-nums tabular-nums; font-feature-settings: "kern", "lnum", "tnum";} code {font-variant: no-common-ligatures lining-nums; font-feature-settings: "kern" 0, "liga" 0, "clig" 0, "lnum";} .fraction {font-variant-numeric: diagonal-fractions; font-feature-settings: "frac";} element {font-variant: small-caps;} @supports not (font-variant-caps: small-caps) {element {font-variant: normal; font-feature-settings: "smcp", "onum", "pnum";}} @supports (font-variant-caps: small-caps) {element {font-variant: normal; font-variant-caps: small-caps;}}" %*

kepubify executes properly, but I have no idea if the above works and I can't seem to find the code in the kepub's css.

Edit: Ah, it's embedded in the html instead. But I still don't know if I did it right. This is what it makes inside the head tags using all of my options:

<style type="text/css" class="kobostylehacks">div#book-inner { margin-top: 0; margin-bottom: 0;}</style><style type="text/css" class="kepubify-extracss">body {font-kerning: normal; font-variant: common-ligatures oldstyle-nums proportional-nums; font-feature-settings: kern, liga, clig, onum, pnum;} h1, h2, h3 {font-variant: common-ligatures lining-nums proportional-nums; font-feature-settings: kern, liga, clig, lnum, pnum;} table {font-variant-numeric: lining-nums tabular-nums; font-feature-settings: kern, lnum, tnum;} code {font-variant: no-common-ligatures lining-nums; font-feature-settings: kern 0, liga 0, clig 0, lnum;} .fraction {font-variant-numeric: diagonal-fractions; font-feature-settings: frac;} element {font-variant: small-caps;} @supports not (font-variant-caps: small-caps) {element {font-variant: normal; font-feature-settings: smcp, onum, pnum;}} @supports (font-variant-caps: small-caps) {element {font-variant: normal; font-variant-caps: small-caps;}}</style><style type="text/css" class="kepubify-fullscreenfixes">body {
    margin: 0 !important;
    padding: 0 !important;
}

body>div {
    padding-left: 0.2em !important;
    padding-right: 0.2em !important;
}</style>

Will that actually work? Sorry for the dumb question; I'm weak on how css works.

Yes, that should work, but note that you can repeat the CSS argument multiple times with a single string each, like "--css 'css1' --css 'css2'".

[JSWolf]

Originally Posted by geek1011

Yes, that should work, but note that you can repeat the CSS argument multiple times with a single string each, like "--css 'css1' --css 'css2'".

Could we have a change so that the extra CSS is read from a file instead of having to be part of the command line?

[geek1011]

Originally Posted by JSWolf

Could we have a change so that the extra CSS is read from a file instead of having to be part of the command line?

No, but I'll probably add an option to store command line options either in a config file or the executable itself.

[JSWolf]

Originally Posted by geek1011

No, but I'll probably add an option to store command line options either in a config file or the executable itself.

One thing I do think needs fixing is to have the extra CSS added to the CSS and not to the HTML. I do not like messy code and having the extra CSS added to every HTML is messy code.

[geek1011]

Originally Posted by JSWolf

One thing I do think needs fixing is to have the extra CSS added to the CSS and not to the HTML. I do not like messy code and having the extra CSS added to every HTML is messy code.

That was a trade-off I made:

Pros:
- Inline CSS is pretty much guaranteed to work.
- Can be done while transforming HTML.
- Doesn't need to modify the package document.
- No path resolving complexities.
- Won't further break broken books as much (kepubify aims to process broken books as best as possible and not make them worse).
- Not as bad as directly adding styles to elements.

Cons:
- Possibly ambiguous escaping of angle brackets.
- Duplicate CSS in each file.
- Not clean and harder to edit, but this doesn't matter too much (the book is generated and not really going to be edited directly after conversion).

If you have any additional disadvantages for embedded CSS, I'd be happy to consider them.

[JSWolf]

Originally Posted by geek1011

That was a trade-off I made:

Pros:
- Inline CSS is pretty much guaranteed to work.
- Can be done while transforming HTML.
- Doesn't need to modify the package document.
- No path resolving complexities.
- Won't further break broken books as much (kepubify aims to process broken books as best as possible and not make them worse).
- Not as bad as directly adding styles to elements.

Cons:
- Possibly ambiguous escaping of angle brackets.
- Duplicate CSS in each file.
- Not clean and harder to edit, but this doesn't matter too much (the book is generated and not really going to be edited directly after conversion).

If you have any additional disadvantages for embedded CSS, I'd be happy to consider them.

.Embedded CSS could cause the HTML to become larger then the size required for the mobile ePub spec. Also, it's more difficult to edit the CSS.