HTML: Move MathJax packages and macros to its configuration#2761
HTML: Move MathJax packages and macros to its configuration#2761Alex-Jordan wants to merge 1 commit intoPreTeXtBook:masterfrom
Conversation
|
I've looked at this closely. I can't check too much further right now, but I think we are unable to alter the MathJax configuration for Jupyter notebooks? Can you test there? Yes, the conversion has been neglected, but no, it has not been abandoned. And there are reasons to move its necessary maintanence up in priority. |
|
I built the sample article with the Jupyter conversion stylesheet. (Requires using Section 7, "Mathematics" has its problems, but the JupyterLite looks like it may a good place to test viewing notebooks. |
|
Does Section 7 have its problems with or without this change? Or only with this change? The I took a short look at Jupyter and how it seems to load MJ. It seems to use the Is it up for consideration to keep things the same for Jupyter notebooks, while making a change like this for HTML? I can appreciate not wanting divergent MathJax details to maintain. It seems that the Jupyter MJ config is what it is though, and in one sense it's already divergent from the config used in PTX HTML. It would be a matter of still getting extensions to work in Jupyter. I won't be fast with this, too many local issues with our term having started. But I think I'll post some sort of record of what I test as I go. |
|
Build was without PR. Jupyter needs lots of work but is not totally wrecked.
…On January 7, 2026 6:38:23 PM EST, Alex Jordan ***@***.***> wrote:
Alex-Jordan left a comment (PreTeXtBook/pretext#2761)
Does Section 7 have its problems with or without this change? Or only with this change?
The `cancel` extension is probably not what we should test with, because it is automatically included when the `autoload` extension is used. Any combined components configuration of MJ that includes TeX input jax loads `autoload`. So for example PTX uses `tex-svg.js`, `tex-mml-chtml.js`, or `tex-chtml.js`, and these all load `cancel` already.
I took a short look at Jupyter and how it seems to load MJ. It seems to use the `mathjax-full` combined component (available with MJ3, but not MJ4). Which I assume also loads `autoload`.
Is it up for consideration to keep things the same for Jupyter notebooks, while making a change like this for HTML? I can appreciate not wanting divergent MathJax details to maintain. It seems that the Jupyter MJ config is what it is though, and in one sense it's already divergent from the config used in PTX HTML. It would be a matter of still getting extensions to work in Jupyter.
I won't be fast with this, too many local issues with our term having started. But I think I'll post some sort of record of what I test as I go.
|
|
I was concerned that this PR might really break Jupyter. Can't test the PR at 30000 feet.
It would of course be best to make no change to Jupyter, while trying to utilize as much common code as possible.
…On January 7, 2026 3:38:23 PM PST, Alex Jordan ***@***.***> wrote:
Alex-Jordan left a comment (PreTeXtBook/pretext#2761)
Does Section 7 have its problems with or without this change? Or only with this change?
The `cancel` extension is probably not what we should test with, because it is automatically included when the `autoload` extension is used. Any combined components configuration of MJ that includes TeX input jax loads `autoload`. So for example PTX uses `tex-svg.js`, `tex-mml-chtml.js`, or `tex-chtml.js`, and these all load `cancel` already.
I took a short look at Jupyter and how it seems to load MJ. It seems to use the `mathjax-full` combined component (available with MJ3, but not MJ4). Which I assume also loads `autoload`.
Is it up for consideration to keep things the same for Jupyter notebooks, while making a change like this for HTML? I can appreciate not wanting divergent MathJax details to maintain. It seems that the Jupyter MJ config is what it is though, and in one sense it's already divergent from the config used in PTX HTML. It would be a matter of still getting extensions to work in Jupyter.
I won't be fast with this, too many local issues with our term having started. But I think I'll post some sort of record of what I test as I go.
|
Alex-Jordan
force-pushed
the
mathjax-macros
branch
from
3925124 to
347c4e7
Compare
|
Only one thing from -html was used in the jupyter conversion: the variable that glues all the packages together, each wrapped in Tested again, and:
I noticed an MJ4 issue I will either post about, or post a fix for. It's an issue that is independent from this PR. |
|
Looks like there needs to be a little more care with how broadly this is used. Claude AI says: Hard blockers — three files not updated
There are also a couple of merge conflicts when I rebase on master. I know what it was that changed recently, but I can't be sure about how to resolve the conflicts. So I did not get very far in verifying the claims above. I did see that (1) seems correct in that the variable is not defined but is used. That should cause XSL to raise an error. Sounds like it will be a while until you can get back to this. Maybe we will be on MJ 4 by then! Let's hope. I'm going to close this temporarily. You or I can re-open it when it can become active again. |
2 participants
We have long put author-demanded packages (cancel, etc) in a
\require{}inside a block of math content. And long placed author-defined macros in the same block of math content.This change moves all of that into the actual configuration block for MathJax. This was motivated by certain changes I'd like to make for WeBWorK, but just seems like the actual appropriate way to do all this. I don't believe it was possible with MJ2, so we did what we did. And held onto it. But with my testing of the sample article with both MJ3 and MJ4, this works.
This warrants lots of testing. I'll try other projects, other browsers, other devices, etc. But I wanted to post it here to see if there is interest in even more people testing. Marking this as draft until I can report more testing.