Bug in Preview with epubs that contain MathML equations?
 

I know that, in Sigil 1.6, Preview is now totally asynchronousis but even so, when someone does click with the mouse somewhere in CodeView, Preview scrolls to show the same text clicked in the source code. Well, nothing of that happens with the epub I attach; no matter the place where I do click in Codeview that Preview remains always in the same place (at the beggining of the file). It seems that something is broken when the epub has MathML equations.

By the way, I don't know why Bibi Reader can't open this epub.

Regards
Rubén

EDIT: The attached epub passes Epubcheck.

I just tested it and had no trouble at all but you have to understand one thing:

Clicking inside a mathml equation in CV or clicking inside an equation in Preview can *never* work.

Neither actually exists in the other.

Inside Preview MathJax replaces the mathml with inline svg of the image.

So when you click in CV inside a mathml tags there is no equivalent node in the DOM inside of Preview.

When in Preview and you click inside an mathml equation, you are clicking in an svg image that has no correspondence in CV.

To use Sigil to navigate by clicking in CV and PV, simply click on any non-mathml element that will exist in both and they will sync.

That is just a limitation of how MathJax works.

As for BibiReader and MathJax, you probably have to load it in the extensions folder inside bibi since bibi itself does not come with or support mathjax.

This is why I really wanted true mathml support in browsers but when Chrome decided to drop it, and replace it with a polyfill kludge (ie. MathJax) it really hurts. As few browsers support true mathml and even fewer support the mml3 extensions (which is what that test case is testing).

If you check it out in calibre which uses Mathjax 3 + you will see much of that testcase is broken because even MathJax in its 3.X versions dropped mml3 support which will hopefully be soon added back.

I'm having trouble on Windows getting it to sync properly (either direction) even when clicking only the html elements. Clicking in the h tags in Code View does not take me to that section in Preview.

Thanks for your answer Kevin. I did what you say, but even so CV and PV don't sync. Do the following:

1. Open in Sigil MathML Case.
2. In CV, go at the end of the sheet, where you read:

and do click here; you'll see that nothing happens in PV, it remains at the start of the view. At least, that is what happens in my Windows system.

Ok; understood :)

I agree with what you are experimenting. That is exactyly what happens in my Windows PC.

It seems from looking at the Inspector in Preview, that MathJax is now injecting lots more crap into the DOM tree than they used to.

The problem is that extra nodes throws off the webpaths (think element counts from the body tag level by level much like an epubcfi) so much they no longer function as they are invalid.

This confuses the go to location very badly. Sometimes it works but other times it does not depending on how many element node counts are off.

Not sure exactly how we can deal with this.

I spent most of today looking at this. It is going to be a bear to fix.

MathJax just inserts so much crap that any type of cfi or element path will be wrong. Very wrong. And it gets worse the more equations are in the file.

If I turn off just about all the crap as I can, it still wraps each math node in a script tag of type math/mml and it adds 2 divs at the top as the first two children of the body. One div is required as it has the svg paths and glyphs needed. The other is just a stupid message field that can not be deleted even if your set showMessages to false and to not display. Even worse the Mathjax java script code will constantly recreate it even if has been deleted and set not to be used.

So the only approach that might work is to register a start-up hook for when mathjax ends and then create some javascript to remove all of the extra script tags added to wrap the math ml tags from the dom, then remember if using mathml and if so compensating for the two extra first children of the body when passing a location into Preview and do the reverse when passing a location out of Preview to CV.

What a mess! All because Chrome decided to kill all support for true native mathml in the browser.

I wouldn't expect anyone to go down that rabbit hole. :eek:

Well call me Alice! ;)

I will try to do this tomorrow just to see how doable and robust this approach would be. If I can get it working reasonably well without the changes being too invasive we can consider it.

If not, we should just leave it as a bug and wait for MathJax 3.x with mml3 support and see if it deals with things any better.

Far be it for me to discourage a man with a plan. ;)

I was just thinking that Preview/Codeview sync is probably able to be broken at any time by scripts included with epubs.

Yes, any scripts that add dom nodes that are first level children of the body tag are going to be an issue. But that would be because of their own javascript and not our internal stuff.

I would like our internal stuff to not impact the sync if at all possible.

You guys are heroes!

Okay, I tried this approach and it seems to work. The changes included modifying the SIGIL_EBOOK_MML_SVG.js file to strip out and turn off a bunch of junk (had to modify the version inside ML.zip as well), plus some special post mathjax run javascript cleanup code, and some routines to compensate for the added 2 divs as the first children of the body when getting and setting location.

I have pushed all of this to master.

If anyone gets a chance, I would love to see if and how this works on Windows (it should) but most importantly if it works with a system level MathJax 2.X on Linux.

If it seems to work on all platforms, we will leave it as is, otherwise if it can not be easily fixed, we can revert it and worry about it again when the mathjax conversion to Mathjax 3.X includes the mml3 extension.

Hope this works!

I confirm in Windows 10.
Of course, jumps to preview only on click h1, h2 and p in the sample file.

Wonderful! Thanks.

I can confirm it works in macOS, so that just leaves Linux.

I will try to fire up my Linux box later tonight and give it a try there, unless someone beats me to it.

I'll check Linux with the system MathJax 2 later on today sometime (unless someone beats me to it). ;)

OK. The bad news is that regardless of this latest change, MathJax rendering isn't working at all with the system mathjax2 on my Arch system. Even with the stock pacman version of Sigil 1.6.0. Inspector shows that the local config is being properly installed and found.

I'll need to find out what's going on there before I can test the latest Preview sync changes.

I take that back. The mathjax url isn't being properly built whenever the system mathjax is being used. There's a path separator missing. It was probably the last change we made to get Mathjax working again on Windows. It works for the bundled mathjax build, just not when the -DMATHJAX_DIR= cmake directive is provided (and the provided path doesn't end with a forward slash).

Other than that, it looks like your latest MathJax sync fixes will indeed work with the Linux system mathjax2 (once I figure out what's going wrong with the url building under that special-cased situation).

Glad to hear it works on Linux once the injected url is fixed!

Yeah. We broke mathjax rendering on any repo versions of Sigil that specify -DMATHJAX_DIR (which may only be Arch right now) starting with Sigil 1.5.1. It's a pretty easy fix, but I want to make sure it's handled in a way that doesn't change how packagers specify the system MathJax location in their existing build scripts.

Everything will already work on Linux for those who use our bundled mathjax. It's only the packagers who debundle with -DMATHJAX-DIR who are affected.

Given the code in MainWindow.cpp, mathjax_dir needs to end with a '/' or we can not just append MathJax.js

Perhaps we check if mathjax_dir.endsWith('/') and if not append one for linux/unix

A *nix check for the slash might be best. Otherwise, a broken url with two forward slashes is technically possible if someone provides a path that end in a slash via MATHJAX_DIR (and we automatically append one in all cases).

Why is there nothing as handy as Python's os.path.join, so we could avoid concatenating with slashes altogether? :D

Please push whatever you think best.

I like your idea of checking if it ends with a slash, and adding it if not (*nix only). That's probably what I'll do.

Thanks!