[Plugin] Epub3 E-Reader Plugins for Sigil
 

To help user's get a better feel for how their epubs will look in some browser-based epub2/epub3 e-readers while still inside Sigil, we have created 3 new Reader plugins for Sigil 1.6.0 or later:

https://github.com/Sigil-Ebook/ReadiumReader/
- based on Readium's cloud e-reader

https://github.com/Sigil-Ebook/BibiReader/
- based on Bibi browser e-reader

https://github.com/Sigil-Ebook/EpubJSReader/
- based on FuturePress's epubJS e-reader

For direct links to the plugin's themselves, see the Plugin Index
https://www.mobileread.com/forums/sh...d.php?t=247431

These plugins will only work Sigil-1.6.0 or later.

Icons for BibiReader and EpubJSReader.

For Bibi, it is the Japanese "Bi" character.

Thank you! I will add then to the next releases.

When I run any of the three plugins, I get the following message:

Status: failed
Launcher: missing or incorrect paths passed in.

What can be wrong? I tried with both, epub2 and epub3 ebooks. And the plugins are installed where they are suppossed must be:

(C:\Users\MyName\AppData\Local\sigil-ebook\sigil\plugins).

TIA
Rubén

EDIT: My bad; files were corrupted. After redownloading the plugins all worked perfectly.
Many thanks for your great work!

I had some weirdness occur when adding and running the plugins as well. But I can't quite the remember the sequence.

I think first I tried to add all 3 plugins, one at a time, but after adding 2 (Bibi and epubJS), Sigil froze. Totally unresponsive. I ended up having to Force Quit Sigil (command-option-escape).

Then I re-launched Sigil and successfully added the 3 plugins (using the same plugin files that I originally downloaded). When I ran Bibi, I got Status failed: Launcher missing or incorrect paths passed in message, but the other two ran successfully.

I quit Sigil and re-launched, and then everything ran smoothly. The plugins weren't corrupted since I never re-downloaded them, just used the same plugin file from the original download.

I realize this probably isn't helpful since I don't have exact sequence and can't reproduce the problem. Just wanted to inform that I experienced some weirdness when adding the plugins and on first-run, but it all worked itself out with quitting and re-launching Sigil.

Curious. Do you know if you added the plugins using the Plugins->Manage Plugins menu route, or did you do the Edit->Preferences menu route and then navigate to the Plugin subpreference?

There's some subtle internal differences in the methods. I'd recommend the first to avoid having to refresh the plugin database with a Sigil restart. Though I can't think offhand why these particular plugins would cause issues in that regard.

On macOS you must download them and then manually move each one outside of your Downloads folder to your Desktop to get Gatekeeper to not try to move them for security purposes.

It is not the plugin itself that is generating that error message, it is the Sigil plugin wrapper code. It will report exactly that error if the plugin you are trying to launch is being secretly moved behind the scenes when run the first time due to Gatekeeper.

My guess is Gatekeeper is also playing around behind the scenes with Sigil too when it is run the first time after installation.

Not sure why it happens on Windows though?

For what it is worth, I installed the 3 plugins from the Plugins => Manage Plugins and added them to my Plugins shortcut bar. The BiBiReader plugin was very slow loading the 453 xhtml files from an anthology I used for testing and was not the speediest at turning pages. The BibiReader plugin also display a portion of the next page if I set the windows width too much wider than the text column on a couple of occasions.

It was rather interesting to see the difference in how they displayed the book I was testing compared to preview and PageEdit.

This is on Windows 10 Pro x64.

Yes, Bibi requires you give it a zipped epub whereas none of the others have that requirement.

So for Bibi the plugin must copy each file in the epub and zip it up just to pass it to Bibi.

Bibi's strength is supposed to be rtl and vertical layouts. I have no epubs to test that with.

Plugins > Manage Plugins

Yes, I did that.

Yes, since it only happened the first-run, that makes sense. Weirdness!

Sometimes, when I want to see how the hyphens could affect a text (and when to avoid them or where disable them), I use the lybrary Hyphenator.js. Sigil supports it very well (even in epub2) and the Preview panel shows hyphens very well.

Of course, I don't include in my epubs (even in epub3) the .js lybrary (because epub2 doesn't support it and for epub3, the ereaders have the feature to hyphen the text) but for that very reason, it's quite a nuisance first to add the lybrary to watch the probably output and then remove it.

But now, that you Kevin and Diap have implemented three plugins as viewers, I'm wondering if wouldn't be possible add the Hyphenator.js lybrary to them (the user could have the option to enable or disable it). By the way, BibiReader seems not to support javascripts.

Many thanks for your considerations.

Kevin would be able to provide more detailed info here, but we're really not doing much of anything other than providing a browser for these totally standalone reading systems to run in. We're not looking to reinvent the wheel by doing a lot of hacking in these separate projects' codebases. We're just basically providing a wrapper for their reading systems to inhabit. A lot of customization will make it more difficult for us to incorporate any upstream changes from those external projects.

That's not to say Kevin might not be more amenable to customizations of this sort. I wouldn't want to speak for him.

Bibi currently disables user javascript in its default setting but I can change that in a future release.

As DiapDealer said, we are *NOT* trying to create our own e-reader here at all.

We are just packaging up existing browser based e-readers so the epub developers can see how their code might work across multiple e-readers while still inside Sigil where changes can be made more easily.

If you want to play around with Bibi and javscripts, you will need to search the bibi folder inside the plugin for a file called defaults.js.

Here is a link to it on github:

https://github.com/Sigil-Ebook/BibiR...ets/default.js

Near the end of that file you will see:
There are other settings in that file that control what happens when you grow the window too wide and many other useful things.

Changing that file in the plugin should allow you to use your hyphenator and control layout a bit better.

Hope this helps.

KevinH

Thanks! :thumbsup:

Okay, I added in BeckyEbook's new plugin icons for both BibiReader and EpubJSReader (thanks BeckyEbook!) and modified the BibiReader default.js to not disable or remove any local epub javascripts (per the epub3 standard).

See BibiReader_v0.2.0.zip and EpubJSReader_v0.2.0.zip from the links in the first post in this thread.

Please Note: Although currently rare - especially inside Sigil where you can see all of the source and given Sigil has a URLInterceptor to help deal with this issue - malicious epubs do exist that can exploit javascript to read in local files and pass them along. So please be careful showing any unknown epubs via these plugins before verifying its contents within Sigil first.

The epub I attach doesn't pass epubcheck if I don't include by hand:

"properties="scripted"

in the respective item of the .xhtml file in the .opf file. Why I include this comment in this thread? Because the epub can be read perfectly with the Readium and EreaderJS plugins but not with Bibi. But I think that the issue is not with Bibi but with its python wrapper. I say that because if I open with my browser the file "Index.html" present in the plugin's Bibi folder, and then I drop there the epub attached, Bibi can open it without problem. For some reason, when Bibi is launched with the plugin, it can't find the file "en-us.js" (maybe is not packeted in the .zip file generated by the plugin) and so can't display the epub.

Yes use the epub3 tools to update the manifest properties. It should look for script tags and update the manifest properly.

I will play around with your test case.

I ran Tools->Epub3 Tools->Update Manifest Properties and it nicely detected the need for scripted and added it. Sigil has always worked like that. So I am not sure what you are asking?

As for Bibi and this epub, I had no trouble with it opening at all.

There is no en-us.js file anyplace in Bibi. It is part of the hyphenator code.

It appear to work just fine on my machine with the Bibi plugin.

Perhaps you might want to try loading the en-js script as well in
your xhtml file:

<script src="../Misc/en-us.js" type="text/javascript"></script>

You are running your tests as an output plugin via Sigil and not using the included demo python file right? That demo file is just there for proof of concept and has not been debugged or even tested much on Windows.

I just checked and the epub/zip handed to Bibi does have all of the js code in it. So if you are seeing a problem, that is not the cause.

But again, I can not see any issues at all on my machine with your epub testcase and Bibi (the latest v020).

Yes, I'm not using "reader_demo_v3.py" file. After installing the plugin, I run it by clicking on its icon in the toolbar.

Yes, of course, I know that :) And I had to change the Hyphenator.js code in order the script were able to localize that file. Originally, Hyphenator has a folder named "Patterns" where are stored the hyphen patterns (not only "en", but also "es", "fr", etc., etc.). But in an epub, it's not possible for Hyphenator to locate the proper language file (because the Patterns folder doesn't exist), so I must include it in the ebook and must tell the script where to find it.

In my system I just can see a blank page after running Bibi v020 plugin with the epub I attached. As I said, with Readium and EpubJS all is ok, but not with Bibi. But I can see epubs not scripted with Bibi.

Are you using BibiReader v020 as I enabled JavaScript in it. When I load your test epub in Sigil and launch it via its icon, I see about 6 pages of text but now that I look again no hyphenation is readily apparent. Perhaps it is not running at all on my machine? And that is why I get no error message.

I will play around with it some more and see if I can get it working.

Bibi May still strip js that is not directly loaded. Did you try adding the script tag for en-us.js as well?

Okay, I got no error because it was not running at all due to a typo I had locally (I was working on a v030 version). Once I reverted to the posted v0.2.0 version I see 6 blank pages with your test case.

In Sigil, I edited Section0001.xhtml and added the following line:

<script src="../Misc/en-us.js" type="text/javascript"></script>

immediately after this line:

<script src="../Misc/Hyphenator.js" type="text/javascript"></script>

And relaunched BibiReader. It showed all 6 pages with hyphenation enabled.

My guess is Bibi will still strip out any unused js files even with that default.js change.

That said, most browsers require a script tag before it will load any js code into memory before it can be used. I see in the Hyphenator code the load patterns routine where you made the change. It literally builds a script tag if it can find the en-us.js file and adds it to the DOM.

Are you sure basePath ends with a "/"?

If it tries to use xhr to load it instead it may run into cross site scripting restrictions. Also I did not see Chrome listed as a supported Browser in any of the Hyphenator.js code I looked at but I only skimmed it.

Hope this helps,

KevinH

I just tried again *without* adding the en-us.js via a direct script tag in the xhtml file and this time it worked perfectly.

So it appears to be something is a bit flakey timing-wize about finding and loading the en-us.js file in Bibi but it is not something easily seen.

Give it a few tries with and without the added script tag and let me know what you see.

In principle, to add the en-us.js file via direct script tag is not neccesary (in fact, the ebook passes epubcheck without it). But I did what you said, and I added the "en-us.js" script tag and, it WORKED!

But the curious thing is that, after removing that tag, it continued working! I can't explain why that behaviour. :)

By the way, the plugins for three different e-readers were very nice additions. Many thanks for that.

That is exactly the same strange behaviour that I am seeing with Bibi and your test case.

I am scratching my head as to why it acts like that.

I took a look at the Bibi js code itself and all that 'allows-scripts-in-content' does is control whether Bibi's DOM strips out all script tags on load or not.

So something is a bit strange with Bibi but it is hard to track down given all of its code has been minimized, and all his code is done via Promises.

Them rewriting the DOM tree so much makes me worry about what else they are stripping out. There is a whole sanitizer.js extension for that.

Sorry I can not be more help here.

No problem Kevin, I appreciate your help. I realize that is not an issue related with your work; the issue is with Bibi. Let's hope no other problem appears :)

Hello everyone! I'm creating a new Epub3 book, making a table of contents. But in EpubJSReader it doesn't work, nothing happens when you click on the links. In other books, everything works fine, including the Sigil help. What could be wrong?

Does it work in BibiReader? Does it work in ReadiumReader?

And most importantly does your epub pass epubcheck?

Yes, it works. It also works in all the android book readers that I tested (Lithium, Moon reader, and others). I checked on validator.idpf.org, no errors.:blink:

Did you run epubcheck? There is an epubcheck plugin for Sigil to make this easy.

I just tried both an epub2 and an epub3 (our new user's guide) in Sigil with EpubJSReader plugin and they both worked flawlessly. There is a TOC icon in the upper left corner, that will produce a sidebar with the TOC properly nested. As I move my mouse over, the TOC entries they get highlighted. If I click on one, the book is moved to that place properly.

So it is working for both epub2 (toc.ncx) and epub3 (nav).

That is why you need to check it with epubcheck (unless that is identical to the idpf validator link) to detect things like missing nav properties on manifest items, etc.

So there is something specific about that epub that is creating the problem as well formed epub2 and epub3 seem to work fine in EPUBJS. I also tried a html toc and those links all worked as well.

Or could it be some Anti Virus or Defender thing stopping local links from being opened?

If you want to you could post that epub3 someplace private and pm "KevinH" here on Mobileread with a link, I will try it on my machine to see if it is machine specific issue or a epub specific issue.

Something even easier to try is to grab the very latest Sigil User Guide epub from here:

https://github.com/Sigil-Ebook/sigil...guide/releases

And load it into Sigil and launch the EpubJSReader plugin. Then hit the toc icon in the upper left hand corner of the reader and try navigating to one of the chapters via that TOC.

If that works, then we know the problem you are seeing is epub specific, If it fails, then the problem is machine specific (AV or other security tool or ...)

Created a new simple epub with minimal editing. In the Sigil help, navigation works fine, so it's not about the antivirus.
Attachment 187545

EpubJSReader seems to be butchering the valid hrefs in the nav when the nav is in the "Text" folder alongside the xhtml files. If I move it into the OEBPS folder (which is where the Sigil Guide's NAV is located), then the updated links ("Text/Section0001.xhtml") seem to work fine.

I can't believe that EpubJS would work only when the nav is not in the same folder as the other xhtml files! That is horrible. I will see if anyone has reported it on the epubjs github site. Perhaps there is a fix there.

I didn't do much testing, but I wouldn't be surprised if it's assuming the nav is in the same location as the opf and/or ncx.

Here are three related bug reports ...

https://github.com/futurepress/epub.js/issues/1084

https://github.com/futurepress/epub.js/issues/1107

https://github.com/futurepress/epub.js/issues/469


It seems to confuse href from nav with an opf relative href. Since the ncx and the opf generally sit together this works but if the nav is in a Text folder it will not.

The 1084 issue has a suggested fix that was never incorporated. I will look into adding it.

Okay, I found the bug location in the TocController code in reader.js. I will try to fix it there and if so post an updated EpubJSReader plugin.

I remember there was something in the upstream Readium Reader code that we tweaked to get things working, too. Should we consider making forks of the relevant repositories so we can document the changes? Or at least keep patches? I think the change to Readium took place before our plugin repository was created. I can't seem to track down our early testing conversation where we found something wrong RE url encoding.

EDIT: whoops! Never mind. I see the included patch for Readium, now. Nothing to see here. ;)