Missing spaces after coverting epub to kepub

[nyamok gajah]

When I converted from epub to kepub after words in italics,bold or words in a <span....> </span> - but not in all cases- spaces were missing after such words. it seems to be random. When I open the epub in the calibre editor I find that in every case where the space is missing, the </span> or </i> is at the end of a line. But the space isn't missing every time the </i> or </span> is at the end of a line.

For example,
for the abundance of milk <i>that</i>
they shall give

Epub displays "for the abundance of milk that they shall give
Kepub displays "for the abundance of milk thatthey shall give

I am using calibre 5.8.1 and no plug-ins need updating

[theducks]

Look at your stylesheet for either the Paragraph style or i style
comment out/remove the letter-spacing line
For some reason that also affects the space between words
(it was affecting Headers on my Aura2. took me a long time to figure out. It seems to make spaces verrrrry thin)

[nyamok gajah]

Many thanks, but there is no letter-spacing in the stylesheet
I replaced every </i> followed by line-break in the html
with </i> followed by a [space] and removed the line-break

The epub converts ok and the spacing after italics is ok

[rashkae]

It would be interesting to know whether the Kobo is ignoring the line break, or if the conversion to kepub is removing the line breaks. Can you tell us how you are converting to kepub? (are you using the Kepub output plugin and explicitely converting, or are you sending to device with the Kobo Touch Extended Driver) ?

[JSWolf]

How are you converting to KePub? Are you using KePubify, the KePub input/output plugins, ad the KoboTouchExtendedDriver?

Also, use the Scramble Ebook plugin and scramble the eBook. Try the conversion on the scrambled eBook, post the scrambled ePub so it can be tested by others.

[davidfor]

Originally Posted by rashkae

It would be interesting to know whether the Kobo is ignoring the line break, or if the conversion to kepub is removing the line breaks. Can you tell us how you are converting to kepub? (are you using the Kepub output plugin and explicitely converting, or are you sending to device with the Kobo Touch Extended Driver) ?

It is the driver. And the conversion should do the same. Somewhere along the way the line break is being lost. I haven't gotten around to looking at when.

The kepub renderer will correctly treat a line break as a space. But, if you highlight text that includes one, it will show when you look at the annotations list.

[rashkae]

Originally Posted by davidfor

It is the driver. And the conversion should do the same.

Err, no, sending through the driver and converting to Kepub (in calibre) will not be the same. Converting within Calibre itself will send the the book through Calibre's whole e-book processing chain. With Default settings, that will make dramatic changes to the book, (and even with all the changes to default I make, there are still things that will get changed during the conversion process, such as font size variable, (small, medium, etc.) being converted to some predefined rem value, (or your custom em values, if you enable font size scaling, the default). Files will get split based on heuristic chanter splitting.. and I'm sure many many other changes I can't point at the top of my head.

Edit: I can not replicate the problem on Calibre 4.8 either way, however.

Edit 2: I upgraded my touch Extended Driver from 3.1.5 to 3.4.1, and my Kepub output to latest as well, and now both reproduce the same issue. (now how to I revert... ha.)

[davidfor]

Originally Posted by rashkae

Err, no, sending through the driver and converting to Kepub (in calibre) will not be the same. Converting within Calibre itself will send the the book through Calibre's whole e-book processing chain. With Default settings, that will make dramatic changes to the book, (and even with all the changes to default I make, there are still things that will get changed during the conversion process, such as font size variable, (small, medium, etc.) being converted to some predefined rem value, (or your custom em values, if you enable font size scaling, the default). Files will get split based on heuristic chanter splitting.. and I'm sure many many other changes I can't point at the top of my head.

Yes, a conversion will do a lot of other things. But, we were talking about what happens when there is a line feed in the middle of the text. And more specifically immediately after a close tag. I know that the calibre conversion doesn't remove line feeds like this. And the kepub conversion is an epub conversion followed by running the same code that add the spans as the extended driver uses, in all likelihood, the line feed will be lost after a conversion. Sure, there are some options in the conversion that would affect this, such as the unwrap lines, but, if the line feeds get through the epub part of the conversion, the kepubification step will trigger the same problem.

Edit: I can not replicate the problem on Calibre 4.8 either way, however.

That doesn't surprise me to much. The driver and conversion use some of calibres routines for this. There were some changes in them earlier in the year that affected the driver and the conversion. This is probably related to those changes and no-one had a book with exactly this formatting to see the problem. Or it didn't worry them.

[rashkae]

@davidfor: Just a quick note to my edit above.. I have confirmed that the problem was introduced at some point after Extended Driver version 3.1.5. So whatever code introduced this, it's not related to the Calibre version.

[rashkae]

I downloaded and tested what versions of the driver I could from the GIT, and have determined that this issue was introduced between 3.2.7 and 3.2.10. Unfortunately, I do not have a copy of 3.2.9. That's probably as far as I'll go tonight

Edit: I was able to test all the commits until (and including) Jun 12, 2020. Unfortunately, when I tried to apply the Jun 15 "Fix Span Processing", it breaks the driver completely on my system.

[davidfor]

I've done some testing and have a fix. I have a pull request in git with the fix.

[rashkae]

Originally Posted by davidfor

I've done some testing and have a fix. I have a pull request in git with the fix.

Thanks.. I do have a new appreciation for how much work tracking an old bug can be... )