suggestion - kepubify: optimize spans for compatibility with text-modifying plugins

[0x6f677548]

The kepubify approach adds spans that interact unexpectedly with text modifications made by other plugins, such as the (Intellireading Metaguiding plugin). This causes performance issues on some Kobo devices, particularly affecting users who rely on accessibility features.

Currently, the plugin wraps each phrase in a `<span class="koboSpan">` tag. When used with plugins that modify text structure (e.g., by adding bold tags), this results in a higher number of spans than intended. For example:

Original text:

Chapter 1

After (Intellireading Metaguiding plugin)

<b>Chap</b>ter <b>1</b>

After kepubify:

<b><span class="koboSpan" id="kobo.2.1">Chap</span></b><span class="koboSpan" id="kobo.3.1">ter</span><b><span class="koboSpan" id="kobo.4.1">1</span></b>

I would like to propose the optimization of the span insertion process by:

1. Avoiding inserting spans on text modification tags (italic, bold, underline)
2. Reducing the overall number of spans inserted


An optimized output could look like this:

<span class="koboSpan" id="kobo.1.1"><b>Chap</b>ter <b>1</b></span>

This approach would maintain the necessary Kobo-specific metadata while preserving text modifications made by other plugins, potentially improving device performance.

Currently, there are no effective workarounds. Users experiencing this issue are facing out-of-memory exceptions and significant slowdowns when loading chapters on their Kobo devices. I am currently testing a device driver approach where epub is converted to kepub before metaguiding, but that seems a bit over-engineering, and it would be great if the base kepubify process could change the way it handles these tags


How useful could this be

This enhancement could be highly useful to a significant number of users, particularly those with dyslexia or other reading difficulties who rely on text-modifying plugins like (Intellireading Metaguiding plugin). It would improve compatibility between accessibility features and device-specific optimizations, enhancing the reading experience for these users while maintaining the benefits of the Kobo TouchDriver.

Additional context

I've reported this issue on the past on the kobotouch extended plugin:
https://github.com/jgoguen/calibre-k...ver/issues/182

let me know your thoughts.
thanks

[DNSB]

Given that there is little empirical proof that modifying the text as suggested does anything to improve reader comprehension or reading speed (much as the various fonts claimed to be better for dyslexic readers have failed to show any reproducible improvement in several studies), IMO, time spent on this is not a good use of calibre's developers time.

As for the out of memory error? I tried using your plugin on an omnibus volume (1371332 words, 10.6MB) and there were no issues with opening it on a Kobo Glo, Clara HD, Sage (4.38.23171). or Kobo Libra Colour (4.41.23145). No out of memory (checked this from a NickelMenu option) nor did I notice any noticeable slowdown between the unmodified and modified versions sent as kepub or epub when opening the ebook or changing chapters.

[JSWolf]

Originally Posted by 0x6f677548

The kepubify approach adds spans that interact unexpectedly with text modifications made by other plugins, such as the (Intellireading Metaguiding plugin). This causes performance issues on some Kobo devices, particularly affecting users who rely on accessibility features.

Currently, the plugin wraps each phrase in a `<span class="koboSpan">` tag. When used with plugins that modify text structure (e.g., by adding bold tags), this results in a higher number of spans than intended. For example:

Original text:

Chapter 1

After (Intellireading Metaguiding plugin)

<b>Chap</b>ter <b>1</b>

After kepubify:

<b><span class="koboSpan" id="kobo.2.1">Chap</span></b><span class="koboSpan" id="kobo.3.1">ter</span><b><span class="koboSpan" id="kobo.4.1">1</span></b>

I would like to propose the optimization of the span insertion process by:

1. Avoiding inserting spans on text modification tags (italic, bold, underline)
2. Reducing the overall number of spans inserted


An optimized output could look like this:

<span class="koboSpan" id="kobo.1.1"><b>Chap</b>ter <b>1</b></span>

This approach would maintain the necessary Kobo-specific metadata while preserving text modifications made by other plugins, potentially improving device performance.

Currently, there are no effective workarounds. Users experiencing this issue are facing out-of-memory exceptions and significant slowdowns when loading chapters on their Kobo devices. I am currently testing a device driver approach where epub is converted to kepub before metaguiding, but that seems a bit over-engineering, and it would be great if the base kepubify process could change the way it handles these tags


How useful could this be

This enhancement could be highly useful to a significant number of users, particularly those with dyslexia or other reading difficulties who rely on text-modifying plugins like (Intellireading Metaguiding plugin). It would improve compatibility between accessibility features and device-specific optimizations, enhancing the reading experience for these users while maintaining the benefits of the Kobo TouchDriver.

Additional context

I've reported this issue on the past on the kobotouch extended plugin:
https://github.com/jgoguen/calibre-k...ver/issues/182

let me know your thoughts.
thanks

What you are doing is not Intellireading. It's actually Bionic Reading. https://bionic-reading.com and Bionic Reading is pure BS. It doesn't work. It just makes it harder to actually read.

If you want to use Bionic Reading, have the plugin do the modification to an ePub eBook and then use calibre to convert to KePub from there. Problem solved.

[DNSB]

Originally Posted by JSWolf

What you are doing is not Intellireading. It's actually Bionic Reading. https://bionic-reading.com and Bionic Reading is pure BS. It doesn't work. It just makes it harder to actually read.

If you want to use Bionic Reading, have the plugin do the modification to an ePub eBook and then use calibre to convert to KePub from there. Problem solved.

Reading his original message, what he wants is for Kovid to add special case logic to hand the mass of <b>....</b> that are added to the code. He claims that those extra spans added around the <b>s are causing out of memory errors and slow chapter turning. I did test his plugin with an ~1.4M word omnibus and could see little difference in performance when I send any of the 4 variants I generated to my Sage. According to running free -m from NickelMenu, none of the 4 variants caused even close to an out of memory issue.