An issue with the .opf

[Moonbase59]

I wonder what will happen with JS/Wasm on older hardware readers? Will they even be able to use it, or will they become horribly slow, thinking of the underpar hardware and usually old software?

I know that my Tolino Vision 5 used Hyphenator (Hyphenopoly’s predecessor) for its "Advanced Reading Experience", and even made a new "de.js" for it. It was… well… acceptable, but that reading mode had other problems as well, so I never used it much.

Guess one needs to check compatibility and performance on real hardware, testing at least for RMSDK and KOReader, probably more.

[DiapDealer]

Originally Posted by RbnJrg

It's easy to test that. Open the epub I sent in Thorium; you'll see that hyphenation works. After that remove the script from the epub sample and open it again in Thorium; you won't see any hyphenation. Maybe things are different on Mac; on Windows and Linux the script works fine.

You seem to be talking at odds with each other. Kevin is saying that he doesn't think it is working at all from within Sigil even with any of the .js plugins. They are hyphenated when using the Readium plugin because WebEngine hyphenation is on by default. Forget all the standalone rendering systems. That's not what he's talking about.

[RbnJrg]

Originally Posted by Moonbase59

I wonder what will happen with JS/Wasm on older hardware readers? Will they even be able to use it, or will they become horribly slow, thinking of the underpar hardware and usually old software?

If the ereaders have support for javascript, it will work fine. Hyphenopoly is fast and it will take one more second to load the .xhtml file to hyphenate text.

I know that my Tolino Vision 5 used Hyphenator (Hyphenopoly’s predecessor) for its "Advanced Reading Experience", and even made a new "de.js" for it. It was… well… acceptable, but that reading mode had other problems as well, so I never used it much.

So far I'm using Hyphenator and works fine but I'm looking to change to Hyphenopoly because is faster. By chance, what is your de.js? Maybe it can be optimized in some way for faster hyphenation.

Guess one needs to check compatibility and performance on real hardware, testing at least for RMSDK and KOReader, probably more.

ADE and KOReader doesn't need Hyphenopoly because they have native support for hyphenation.

[RbnJrg]

Originally Posted by DiapDealer

You seem to be talking at odds with each other. Kevin is saying that he doesn't think it is working at all from within Sigil even with any of the .js plugins. They are hyphenated when using the Readium plugin because WebEngine hyphenation is on by default. Forget all the standalone rendering systems. That's not what he's talking about.

I understood. Maybe I didn't explain myself well. Kevin uses also Linux. So, let him (or do it you, since you have Arch) run the following test on Linux:

1. Remove the following line from the header of the sample epub I sent:

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

2. After that, open the epub (in Sigil) with the Readium plugin. No hyphenation should appear, even when hyphenation is enabled in the .css file.

After that, if the link with the .js file is enabled, Readium will show hyphenated text.

[DiapDealer]

I'll check it when I get a chance. Kevin's mainly on macOS. I'm the one only primarily on Linux

[KevinH]

Okay, so my problem was how I forced it to use Hyphenopoly by adding my own config info, made it ignore the path you had internally set.

So I changed the _loader.js to enable "FORCEHYPENOPOLY", in its internal config and I can see from the Inspector and the javascipt error console that the wasm file is being found and loaded and that Hyphenopoly.js is being loaded as a blob.

All as expected, but how can I tell if it is actually working or not given hypehnation is built in (at least on macOS)?

So this is an improvement but it requires the following change (which I just pushed to Sigil master):

diff --git a/src/main.cpp b/src/main.cpp
index ee33f91ce..26290878c 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -372,10 +372,11 @@ int main(int argc, char *argv[])
 
     // register the our own url scheme (this is required since Qt 5.12)
     QWebEngineUrlScheme sigilScheme("sigil");
-    sigilScheme.setFlags(QWebEngineUrlScheme::SecureScheme |
-                         QWebEngineUrlScheme::LocalScheme |
-                         QWebEngineUrlScheme::LocalAccessAllowed |
-                         QWebEngineUrlScheme::ContentSecurityPolicyIgnored);
+    sigilScheme.setFlags( QWebEngineUrlScheme::SecureScheme |
+                          QWebEngineUrlScheme::LocalScheme |
+                          QWebEngineUrlScheme::LocalAccessAllowed |
+                          QWebEngineUrlScheme::ContentSecurityPolicyIgnored |
+                          QWebEngineUrlScheme::FetchApiAllowed  );
     // sigilScheme.setSyntax(QWebEngineUrlScheme::Syntax::Host);
     sigilScheme.setSyntax(QWebEngineUrlScheme::Syntax::Path);
     QWebEngineUrlScheme::registerScheme(sigilScheme);

which tells Sigil to allow our "sigil:" schmemehandler to use the fetch api.

Update:

The problem is QWebEngineUrlScheme::FetchApiAllowed is only allowed in Qt 6.6.0 and later.

I will have to ifdef that to Qt version.

[KevinH]

Okay, with only the following additional change, your Hyphenopoly should now work in Sigil.

diff --git a/src/main.cpp b/src/main.cpp
index 26290878c..65145a89f 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -372,11 +372,20 @@ int main(int argc, char *argv[])
 
     // register the our own url scheme (this is required since Qt 5.12)
     QWebEngineUrlScheme sigilScheme("sigil");
+
+#if QT_VERSION < QT_VERSION_CHECK(6, 6, 0)
+    sigilScheme.setFlags( QWebEngineUrlScheme::SecureScheme |
+                          QWebEngineUrlScheme::LocalScheme |
+                          QWebEngineUrlScheme::LocalAccessAllowed |
+                          QWebEngineUrlScheme::ContentSecurityPolicyIgnored );
+#else
     sigilScheme.setFlags( QWebEngineUrlScheme::SecureScheme |
                           QWebEngineUrlScheme::LocalScheme |
                           QWebEngineUrlScheme::LocalAccessAllowed |
                           QWebEngineUrlScheme::ContentSecurityPolicyIgnored |
                           QWebEngineUrlScheme::FetchApiAllowed  );
+#endif
+
     // sigilScheme.setSyntax(QWebEngineUrlScheme::Syntax::Host);
     sigilScheme.setSyntax(QWebEngineUrlScheme::Syntax::Path);
     QWebEngineUrlScheme::registerScheme(sigilScheme);

I have now pushed this additional change to Sigil master.

So in the next release of Sigil, Hyphenopoly should work for anyone using Sigil built with Qt 6.6 and later. We currently ship with Qt 6.8.2 and plan to move to Qt 6.9.2 (or .3) sometime in the future.

[RbnJrg]

Originally Posted by KevinH

So I changed the _loader.js to enable "FORCEHYPENOPOLY", in its internal config and I can see from the Inspector and the javascipt error console that the wasm file is being found and loaded and that Hyphenopoly.js is being loaded as a blob.

Great!! Then Hyphenopoly must work in Sigil.

All as expected, but how can I tell if it is actually working or not given hypehnation is built in (at least on macOS).

Ok. Try the following:

1. In the sample epub I sent you, change the style .hyphenate to:

.hyphenate {
  hyphens: manual;
  -moz-hyphens: manual;
  -webkit-hyphens: manual;
  -ms-hyphens: manual;
}

So, even if the hyphenation is set to manual in the style sheet, it will still be applied to the <body> selector and its descendants (i.e., the entire .xhtml file) but this time by Hyphenopoly, not for the MAC native support. MAC only will apply hyphens when it finds a "shy" char in the text and there is none.

2. Employ "FORCEHYPHENOPOLY" to force the loader to load Hyphenopoly.js and the .wasm file.

3. THIS IS VERY IMPORTANT: in your config section you must add the following:

    setup: {
        selectors: {
            "body": {
                compound: "all",
                leftmin: 1, // This is not neccessary but will hyphenate more words
                rightmin: 2 // This is not neccessary
            }
        }
    }

So, your whole config section should look like the following (you'll do better if copy and paste):

Hyphenopoly.config({
    require: {
        "es": "FORCEHYPHENOPOLY",
    },
    paths: {
        patterndir: "../../META-INF/"
    },
    setup: {
        selectors: {
            "body": {
                compound: "all",
                leftmin: 1,
                rightmin: 2
            }
        }
    }
});

With the .hyphenate style in the .css sheet set in "manual", the native hyphenation will be disable and in Readium (or JSReader) hyphenation will only be controlled by Hyphenopoly.

[RbnJrg]

Originally Posted by KevinH

So in the next release of Sigil, Hyphenopoly should work for anyone using Sigil built with Qt 6.6 and later. We currently ship with Qt 6.8.2 and plan to move to Qt 6.9.2 (or .3) sometime in the future.

Great!! Thank you very much for your efforts!!

[RbnJrg]

Hi Kevin;

Is there any way to employ the command "Move..." in order to move a .wasm file from "Misc" to "META-INF"?

[KevinH]

I do not think that would work. The files inside META-INF aside from the container.xml and font obfuscation encryption xml are supposed to be left alone.

In fact in BookBrowser the move command strictly enforces no destination inside META-INF. It does this because the Move command means that the opf manifest and all files must have all links walked and possibly changed as a result of a Move. So files not listed in the manifest should not be moved by the Sigil Move command.

Have you tried writing a plugin to move those files?

[RbnJrg]

Originally Posted by KevinH

Have you tried writing a plugin to move those files?

No, so far I've been moving those files by unpacking the epub and placing the necessary files directly into META-INF and then repackaging the epub.
WinRar provides a fairly simple way for me to do this because it opens the epub without needing to change the extension, and I can add the file from the WinRar window itself. But I was curious if I could use Sigil's "Move..." command.

[KevinH]

Originally Posted by RbnJrg

No, so far I've been moving those files by unpacking the epub and placing the necessary files directly into META-INF and then repackaging the epub.
WinRar provides a fairly simple way for me to do this because it opens the epub without needing to change the extension, and I can add the file from the WinRar window itself. But I was curious if I could use Sigil's "Move..." command.

If you want to test Hyphenopoly under the future version of Sigil that enables the fetch api in Sigil's scheme handler, you may want to check out this post:

https://www.mobileread.com/forums/sh...1&postcount=34

Those testing binaries have the fetch api change in them as well.

[RbnJrg]

Originally Posted by KevinH

If you want to test Hyphenopoly under the future version of Sigil that enables the fetch api in Sigil's scheme handler, you may want to check out this post:

https://www.mobileread.com/forums/sh...1&postcount=34

Those testing binaries have the fetch api change in them as well.

Thank you very much Kevin, it works flawlessly! Great work!!

PS: Bibi Reader has the same issue with the Fecth API; by chance, would it be possible for you to enable that feature also in the plugin? (of course, if it takes you a long time, forget about it, that it's not the end of the world that Bibi doesn't support the Fetch API either.)

[KevinH]

That is inherent to Bibi which I think must use its own scheme handler. I will take a look, although I doubt there is much I can do given the way Bibi handles files it loads.