Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow tex packages that load font extensions to work better with \require and renderer changes. #1080

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

dpvc
Copy link
Member

@dpvc dpvc commented Apr 1, 2024

This PR is for beta.6.

The addition of the new TeX packages that load various double-struck fonts has broken the previous separation of input and output jax. There are some assumptions that relied on this separation, so these new TeX packages complicate things somewhat. In particular, switching renderers when one of these packages has been loaded via \require would not necessarily retain the font in the new renderer. Furthermore, because of the way the extensions hooked into the renderer changes, leading a second font extension would interfere with the loading of the first one when a renderer change occurred.

The component packages for these extensions tried to set things up overcome some of these complications, but were not completely successful. So this PR includes changes to properly handle switching renderers and fonts, both in regular pages and in the v4-lab. In addition, it implements generic font extensions that are not tied to a particular base font, so that the extensions like mathjax-dsfont can be applied to any font.

One of the important changes is to move the code that adds an extension to a font from the TeX component file (where it currently is) into the font extension's component file instead. So all the code controlling the extension being added to a font is now in the extension itself, rather than in the TeX package. The TeX package file now simply has to set up the loading of the extension and that is it. This is done via the changes to the components/mjs/input/tex/extension.js file.

To facilitate this, and to overcome the problem with multiple font extensions, the loader has been extended to include a new function addPackageData() that can be used to update the loader package information (like the checkReady() function), and that data can now include a list of additional packages to load after the initial one is loaded. So we can now set up several font extensions to be loaded when the output jax is changed, for example.

There is also an array of extensions that need to be installed when the renderer changes that is set when one of the font extensions is loaded by \require (in case the new renderer has already been loaded, and so the file-based hooks will not be triggered). This is referenced by the changes in the \require macro, which sets a corresponding array in the document's Menu object, and that is used by the menu code to install the needed extensions when the output jax changes.

Because of the extraLoads array, the Package object gets a new method loadPromise() that returns a promise that is resolved when all the extra files are loaded, and the checkReady() method (if any) resolves. This is also used in the components/mjs/output/util.js file to make sure these files are loaded when a new output jax component is loaded.

Some other cleanup is also performed. The addExtension() functions in the common and chtml output jax files now have the optional prefix argument that the FontData version has (though it is not currently used), and the instance versions of these functions now take a FontExtensionData object rather than an extension name, so that we don't have to store that data in the dynamic extension data. (Since these addExtension() calls have been moved to the font extension components themselves, and those have access to the font data, that means we don't need to keep that data in the saved dynamic extension object any longer). The dynamic extension data now uses a default value for the prefix, rather than requiring it to be set in the font extension component, as in the past.

Finally, some of the config files have been updated to remove exclude arrays that are no longer needed.

This branch requires changes in the font components, as well as the font tools, and also the v4-lab. You will need to check out the generic-extensions branches in the font-tools and fonts repositories, then compile the font-tools, and rebuild the extension fonts (all three). Then check out the lab-extension-update in the MathJax-dev repository. Finally, link the newly built fonts into MathJax-dev's node_modules directory next to the other fonts.

Copy link
Member

@zorkow zorkow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When trying this out in the lab it installed the mathjax-X-font-extension packages but it was looking for the mathjax-X-font packages in node_modules. Is that correct? In other words, will the updated font extensions be published under the latter package name?

@dpvc
Copy link
Member Author

dpvc commented Apr 2, 2024

You're right, they should have -extension. I'll fix that. It is in the v4-lab.js file (setting the loader.source to redirect to the node_modules versions rather than the CDN versions.

@zorkow
Copy link
Member

zorkow commented Apr 8, 2024

After updating the lab, I am now getting the following error:

Invalid option "enrich" (no default value).

I have not yet had a chance to look into it in detail why. I think it comes from the mml3 module.

@dpvc
Copy link
Member Author

dpvc commented Apr 9, 2024

I'm not getting that error. Using the lab-extensions-update branch in the dev repository and merging the font-extension-support branch in the src repository, the lab works as expected.

Otherwise, you can use the v4-lab branch in dev with the develop branch in src, but that won't handle the font extension packages properly.

The enrich message you re getting suggests that either you have something cached that shouldn't be, or that the src branch hasn't been recompiled, or that you aren't on a branch with the menu-fixes merged in.

@zorkow
Copy link
Member

zorkow commented Apr 15, 2024

I have been going back and forth with this a few times and I believe that I can rule out a caching error. It happens in multiple browsers, etc. The issue seems to be that some of the elements of menuOptions.settings are not in the named options.

Are you sure you have not forgotten to push a commit?

@dpvc
Copy link
Member Author

dpvc commented Apr 16, 2024

I'm using a test branch from develop that merges in the font-extensions-support. It looks like the font-extensions-support branch by itself is not enough. It looks like it was the fix/ff_safari_issues branch that includes the sre-menus changes that are what are needed to resolve this problem. So try merging font-extensions-support into a branch off of develop. Sorry for the bad instructions. I knew the sre-menu branch had been merged, but didn't realize it wasn't in develop until after the font-extensinos-support branch was split from develop.

@dpvc dpvc force-pushed the develop branch 3 times, most recently from b77df61 to 1f851dd Compare April 25, 2024 16:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants