Kepub format questions

Originally Posted by jackie_w

KTE never does a full conversion to kepub, it only does a format-shift from epub to kepub.

Not familiar with that term, what is a 'format shift' and how does that differ from conversion? Do you mean just renaming the file extension, or are there additional steps it does?

[davidfor]

Originally Posted by Gorcsev

thank you

Unfortunately what are the kepub expectations for the best rendering result is not very well documented.

For the record, kepub is not any sort of open standard. It is a Kobo only thing and they don't publish much about it. Strictly, it is for books purchased and downloaded from their store to their devices and apps. Again, they don't really support sideloading kepubs as a normal reading format. The only reference to sideloading them I have seen is for book creator to sideload a epub as a kepub for testing purposes.

The only thing that Kobo put out about kepubs is https://github.com/kobolabs/epub-spec. And that is about how to produce good a good input epub for the processing they do. Everything else we know has come from examining the purchased kepubs and experimenting.

[davidfor]

Originally Posted by maximus83

Not familiar with that term, what is a 'format shift' and how does that differ from conversion? Do you mean just renaming the file extension, or are there additional steps it does?

The calibre conversion does a lot more than what the KoboTouchExtended driver. It will probably change every element in the book. It actually works by converting the input book to a common format and then writing that to the output format. In doing this, it will probably completely rewrite the CSS. As well, elements of the HTML code will change, the internal files can be split or merged, the ToC can be rebuilt and lots of other things will happen. Plus it can make changes to what the book looks like when read.

The KoboTouchExtended driver "simply" wraps spans around each sentence in the book. And adds a couple of divs around each chapter. It doesn't change the existing CSS, the internal file structure or the ToC. It shouldn't result in any difference in how the book looks like except what is inherent in using the kepub renderer instead of the Adobe RMSDK.

I usually use the word "transform" to describe the action of the KoboTouchExtended driver to distinguish it from a calibre conversion. I can't decide if "Format shift" is a better term for this or not.

[Gorcsev]

Hi,

I am using KTE sending books to kobo in kepub format. I found a strange behavior handling the "endash". The following happens by sending to the device (a=Lowercase, A=Uppercase):

a – a not converted
a – A not converted
a. – a not converted
a. - A endash => minus sign
a! – a not converted
a! - A endash => minus sign
a? – a not converted
a? - A endash => minus sign
a: – a not converted
a: - A endash => minus sign
a… – a not converted
a… - A endash => minus sign

I have checked the container.py but I didn't find if that is happening there.
I have checked the kepubify it doesn't do it.
I would like to keep en-dashes wherever they exist in my original epub.

[davidfor]

Originally Posted by Gorcsev

Hi,

I am using KTE sending books to kobo in kepub format. I found a strange behavior handling the "endash". The following happens by sending to the device (a=Lowercase, A=Uppercase):

a – a not converted
a – A not converted
a. – a not converted
a. - A endash => minus sign
a! – a not converted
a! - A endash => minus sign
a? – a not converted
a? - A endash => minus sign
a: – a not converted
a: - A endash => minus sign
a… – a not converted
a… - A endash => minus sign

I have checked the container.py but I didn't find if that is happening there.
I have checked the kepubify it doesn't do it.
I would like to keep en-dashes wherever they exist in my original epub.

Any chance of telling us exactly what you are doing? And where you are seeing this? And it would probably be better to post actual HTML source to show what the starting point is.

Also, if you are reporting a bug against the KoboTouchExtended driver, there is a dedicated thread for discussion it in the calibre Plugin forum. It is better to report bugs there.

[Gorcsev]

Originally Posted by davidfor

Any chance of telling us exactly what you are doing? And where you are seeing this? And it would probably be better to post actual HTML source to show what the starting point is.

Also, if you are reporting a bug against the KoboTouchExtended driver, there is a dedicated thread for discussing it in the calibre Plugin forum. It is better to report bugs there.

I just tried to explain in which situation KTE converts "endash" to "minus sign".

I do not know whether it is a bug or it is a feature of the KTE.

The chance: I am sending epub books to kobo with the help of KTE. I just demonstrated how KTE handling the "endash" in different situations. I thought is better so than sending here an HTML file and you should hunt for those places in flowing text. (in HTML you would see just endash(u2013) and minus where it is converted).

My observation: KTE converts the endash to minus every time when it thinks it is a sentence end. On other cases, it not converts.

As I said, I want to keep endashes, while they are in my epubs intentionally where they are.

[davidfor]

Originally Posted by Gorcsev

I just tried to explain in which situation KTE converts "endash" to "minus sign".

I do not know whether it is a bug or it is a feature of the KTE.

The chance: I am sending epub books to kobo with the help of KTE. I just demonstrated how KTE handling the "endash" in different situations. I thought is better so than sending here an HTML file and you should hunt for those places in flowing text. (in HTML you would see just endash(u2013) and minus where it is converted).

My observation: KTE converts the endash to minus every time when it thinks it is a sentence end. On other cases, it not converts.

As I said, I want to keep endashes, while they are in my epubs intentionally where they are.

Firstly, yes, explain what is happening and what you think should happen. But, supplying an example of the code means that others don't have to create it. Especially if you are doing something unusual. For example, are you using a unicode character, or an HTML entity? It also means anyone testing will be starting from the same point.

And you still haven't said what you are actually doing. But, my guess is that you have turned on the "Smarten punctuation" option of the driver. Turning that off will probably fix things, but, means other punctuation isn't "smartened". But, if you have endashes in the book already, that has probably already been done.

And the reason for suggesting you post elsewhere (specifically here) is because that is the thread for discussing the KoboTouchExtended driver. That is where the developer hangs out and hence more likely to get the attention of the person who can do something about it.

[Gorcsev]

Originally Posted by davidfor

Firstly, yes, explain what is happening and what you think should happen. But, supplying an example of the code means that others don't have to create it. Especially if you are doing something unusual. For example, are you using a unicode character, or an HTML entity? It also means anyone testing will be starting from the same point.

And you still haven't said what you are actually doing. But, my guess is that you have turned on the "Smarten punctuation" option of the driver. Turning that off will probably fix things, but, means other punctuation isn't "smartened". But, if you have endashes in the book already, that has probably already been done.

1: what I am doing: nothing other than just simple sideload epub to Kobo. Yes explained in two posts that I am using Unicode character: the endash in my original epub (so it is not here of a result smarten punctuation, but I placed them in the original word -> epub document)

2: testing: I gave several examples. Anyone who interested in it could be try.

Questioning isn't shaming. Answering in offending style it is.

[rashkae]

Originally Posted by Gorcsev

1: what I am doing: nothing other than just simple sideload epub to Kobo. Yes explained in two posts that I am using Unicode character: the endash in my original epub (so it is not here of a result smarten punctuation, but I placed them in the original word -> epub document)

Just post the sample epub you're testing with.. (the resutling Kepub from the device would also be ideal.) That will remove any ambiguity or guessing.

The Smarten Punctuation option David Was referring to is a check box option of the KoboExtended Driver.

Originally Posted by Gorcsev

Questioning isn't shaming. Answering in offending style it is.

For a second, I thought a good deed was about to go unpunished. Thank you for maintaining universe stability.

[davidfor]

Originally Posted by Gorcsev

1: what I am doing: nothing other than just simple sideload epub to Kobo. Yes explained in two posts that I am using Unicode character: the endash in my original epub (so it is not here of a result smarten punctuation, but I placed them in the original word -> epub document)

2: testing: I gave several examples. Anyone who interested in it could be try.

Questioning isn't shaming. Answering in offending style it is.

Sorry, but there are so many problems with your response:

Firstly, as you are using the KoboTouchExtended driver, it isn't "just simple sideload epub". The driver is making changes to the book to transform it to a kepub.

Then it seems you are converting from Word to ePub. I'm not completely sure if the endash is in the Word document, or you have edited the ePub to add them in.

Then, I don't know how you know the endash has been changed to something else. Are you editing the kepub generated on the device? Or are you reading the book on the device and can tell the difference?

Then my comment about the "Smarten punctuation" was because if you have that option turned on in the driver, then maybe that is what is causing the problem. And that the only times I ever see endashes in books are when the "smarter" punctuation is in use. Whether that is because the tool that was used to create the book did this automatically, the conversion to epub did it or it was done as a separate step, I don't know. But, because of that, I was suggesting that you turn the smarten punctuation option off in the driver if you had turned it on. And whether it was on or off is important for anyone trying to reproduce the problem.

Now, to reproduce the problem, I have to create a test epub, send it to the device as an epub to see what happens. Then enable the KoboTouchExtended driver and send it to the device again to see what happens. Then examine the options available and see if there is a combination that trigger the fault. All that takes time. And I am willing to spend the time. And I have demonstrated that here many times. But, I also don't want to waste time if I am note sure what I am trying to achieve.

I have just tried to reproduce the problem. But, I'm stuck as to what to put in the sample. Do I just cut-and-paste what you have above and wrap p tags around each line? That's what I have done in the attached test case. When I send that to one of my devices using the KoboTouchExtended driver and what I think are the likely options, I don't see any changes in whether the character is an endash or not.

Or are the above what you see in the book when you send it to the device? Or is it in pairs? The first line is the input, the second line is the output?

[davidfor]

Originally Posted by Gorcsev

Hi,

I am using KTE sending books to kobo in kepub format. I found a strange behavior handling the "endash". The following happens by sending to the device (a=Lowercase, A=Uppercase):

a – a not converted
a – A not converted
a. – a not converted
a. - A endash => minus sign
a! – a not converted
a! - A endash => minus sign
a? – a not converted
a? - A endash => minus sign
a: – a not converted
a: - A endash => minus sign
a… – a not converted
a… - A endash => minus sign

I have checked the container.py but I didn't find if that is happening there.
I have checked the kepubify it doesn't do it.
I would like to keep en-dashes wherever they exist in my original epub.

Is what you are saying that if you have:

[lower case letter][punctuation][space]endash[space][upper case letter]

That the endash gets converted to a dash?

If so, it is not obvious from the above. And I cannot reproduce it.

[Gorcsev]

thank you for the investigation

I will review all my settings, (including the language settings on windows and application level as well). I feel the problem is around there, or maybe in the word doc cleaning -> HTML procedure makes it.

Next time when I have a problem I will try to be more precise.

thank you again

[Gorcsev]

I have the following in my CSS:
.mono {
display: block;
font-family: monospace;
text-align: justify;
line-height: 130%;
widows: 2;
orphans: 2;
}

with the intention to display monospaced fonts in epub. It works in epub. Could it be reached in kebub as well without using embedded fonts?

[jackie_w]

Originally Posted by Gorcsev

I have the following in my CSS:
.mono {
display: block;
font-family: monospace;
text-align: justify;
line-height: 130%;
widows: 2;
orphans: 2;
}

with the intention to display monospaced fonts in epub. It works in epub. Could it be reached in kebub as well without using embedded fonts?

This may be more effort than you're prepared to do, but you could experiment with this:

1. Kobos don't have any built-in monospace font files so you first need to sideload one. For this example assume you sideloaded the 4 "Courier New" font-family files. You probably also need to power off/on to get the new font properly recognised by the Kobo.
2. You will also need to use the kobopatch system to patch the firmware's override CSS file for kepubs. If you don't you'll be wasting your time with the rest because the default override CSS for font-family on kepubs is:
   

   * { font-family: %1 !important; }

   i.e. whatever font you pick from the font menu will be used for absolutely everything.
   
   The relevant patch name is 'Un-Force user font-family in KePubs' and there are 3 different options to choose from.
   
   
3. Code your book CSS like this, where the red bit is the exact internal font name of your sideloaded font.
   

   .mono {
     ...
     font-family: "Courier New", monospace;
     ...
   }

   You won't need to add @font-faces for kepub, the correct font name is enough.
   
   This CSS should work equally well no matter whether you transfer the book as a kepub or a standard epub.

Item 1 needs to be done only once per Kobo device.
Item 2 needs to be done after every firmware update.
Item 3 needs to be done for every book which needs a monospace font.

[Gorcsev]

thank you

for item2: is it possible just to use "kobo_extra.css" in the device root directory (used by KTE) to override the CSS? (so I don't need patch)