I will take a look but you should really file an official bug report at the epubjs-reader and or epubjs github site. They are the experts in this. I am truthfully not much of a javascript dev as it came after most of my official training was long done I just picked up pieces here and there.

What happens if you set width to 99%? Or to 100vw?

It's the same; I discovered that the plugin running at a full windows doesn't respect the width of an image when that width is between 100%-81%. When the images have a width lower than 80%, those ones are displayed well both in a half and full window.

(we cross-posted)

By trial and error it seems that it is not just 100% but 99%, 95%, 85% etc that cause the issue.

The reader computes a max-width on all images and add that to the readers own css. It does that by using the columnWidth and computing the images paddingRight and paddingLeft.

This works fine when only 1 column (single page) is shown. But when a double-page spread is done, then this computed paddingLeft and paddingRight are incorrect causing the added max-width property to come into play (when it should not).

I can tell it to ignore the paddingLeft and paddingRight when in two page spread mode (2 columns) and then things work but this will break times when images are floated left or right for text to wrap around it.

I have no idea of the "correct solution". If I change this we will just be trading off one error type against another.

I can say that the latest epub.js has changed a lot for the page spread mode (two column) and that it is still in a very fragile state.

Many of their size calculations in two page spreads are inconsistent (such as how they use the gap between page spreads (columns) and they make no sense to me.

Even its calculation of columnWidth is not quite correct and inconsistent with code in other places.

If you have a window of width "width" and gap between the columns of "gap" they seem to be calculating columnWidth in a strange way ...

For divisor = 2 (a two page spread)

columnWidth = (width / divisor) - gap
pageWidth = columnWidth + gap

when in fact the correct calculation would be:

columnWidth = (width - gap) / divisor
pageWidth = columnWidth + (gap / divisor)

but this is inconsistent with other layout code and so it all breaks down someplace else when corrected.

There is also very very little code documentation.

So you will need to file a bug report with the epub.js code github project and give them your Testcase and image explaining the problem.

All in all, I would stay away from two-page spread mode when using EpubJSReader to verify your epub layout. You can use the other two for that.

If you want to play around with the workaround, edit epub.js in the reader folder and look for a routine called "adjustImages" near line 10655

In that routine you will see this line:

let horizontalPadding = parseFloat(computed.paddingLeft) + parseFloat(computed.paddingRight);

But this horizontalPadding is incorrect in two page spread mode.

To workaround it just after that line I added the following:

+ if (this._layout.divisor > 1) {
+ horizontalPadding = 0;
+ }

This seems to fix the problem but will probably not work when images are floated either left or right.

Thank you very much for all the work you have taken! I will do what you say; thanks again :thanks:

I think the bug here in 2 page spread mode is that the columnWidth already accounts for the gap between columns (pages) and so only the leftPadding should be used in calculating max-width on left hand side pages while rightPadding alone should be used in calculating max-width of right hand side pages but that routine does not seem to know which side of the two page spread is being used.

But this is just a guess. I would need to run your test case in a browser with the reader software and check out the values of the padding via the java console to try to really understand what is going on here.

That said perhaps adding back in the gap to the columnWidth in the calculation will make it work correctly without the need to zero it out.

If you get a chance, please try the following bug fix that hopefully will fix both single and double page spreads.

In edit epub.js in the reader folder and look for a routine called "adjustImages" near line 10655

In that routine you will see this line:

let horizontalPadding = parseFloat(computed.paddingLeft) + parseFloat(computed.paddingRight);

Please change this line to be:

let horizontalPadding = parseFloat(computed.paddingLeft) + parseFloat(computed.paddingRight) - this._layout.gap;

Also remember to *remove* this hack if you did add it.

+ if (this._layout.divisor > 1) {
+ horizontalPadding = 0;
+ }

gap is 0 in single page spreads but already accounted for in double-page spreads and by subtracting it out of horizontalPadding we can prevent double counting.

Hope this works for everything. If so let me know and I will add it in officially and make a new release.

I tell you that I applied your first patch:

and EpubJS showed correctly the images at one and two columns, even with float images. So it seems that after zeroing horizontalPadding in two columns layout, images are displayed fine.

But I also applied your second patch, and it worked flawlessly! No more issues when the ereader is displaying images at one or two columns, even with floating images. You did it :) You found and fixed the bug. What a great work!! Thank you very much Kevin. I think that in new versions of your plugin, you can safely include your patch in epub.js.

EDIT: I forgot to tell you that with your second patch, you even improved the separation (the gap) between the two columns in the full window layout. So, your second patch is the full solution for the bug.

Good to know. Thank you for testing that change. I will create an official patch and try to get a new release out tomorrow sometime.

Thanks

@KevinH: Are you beginning to regret creating the Epub3 reader plugins?

Not really. I personally like to test my epubs in readers and these plugins help me do that while still inside Sigil where I can easily change things. So I was really scratching my own itch.

That said, I am personally disappointed in the code quality of these e-readers. All of them have had bad bugs that should have been stamped out long ago. I am beginning to think that devs who generally do only javascript development are just not well trained in computer science, lack engineering understanding of interface design, etc. That or the language itself is just too unstructured, with too many poor quality external libraries and crap all loaded via npm and minimized and scrambled that makes debugging it too hard.

Hopefully, I have fixed or worked around most of the worst of them.

At some point, I will have to stop digging into things like this if they take up too much time from Sigil, but being retired now frees things up a bit and puzzle solving===bug fixing for me and it has always been fun and keeps my brain occupied.

And current Sigil master seems to be in good shape right now!

Take care,

KevinH

I was getting curious about that since you seemed to be trapped into spending time trying to fix bugs in code you hadn't written.

That is true! I just did not think when I started this, they would have so many visually obvious bugs.

Take care,

KevinH

EpubJSReader v0.4.0 is now available. See the first post in this thread for the Release link.

I discovered a new bug, this time in Bibi Reader and with svg images.

When I inserted a svg image by using the <img> tag, Bibi was able to displayed without problem:

Attachment 187658

But when I wanted to insert the same image but with a svg wrapper, I got the following output:

Attachment 187659

Since the same image was able to be displayed without issue by using a img tag, evidently Bibi could show svg images and I supposed that the problem should be in the svg wrapper. Then I tried with a png image (with the same draw as the svg one) inside a svg wrapper to see what would happen:

Attachment 187660

Since Bibi was able to show png images inside a svg wrapper, the problem wasn't in the wrapper. Evidently, the issue was in that Bibi couldn't find the svg image. (Below I attach the respective epub).

So, after opening Bibi.js I found and I changed the following statements:

This:
is replaced by:
and this:
is replaced by:
After those changes, Bibi was able to display svg images also inside a svg wrappers. I report this, because maybe you Kevin can include these changes in future releases of Bibi plugin.