我可以配置 MathJax 进行智能匹配吗?
我可以指示 MathJax 接受多个基本分隔符对吗?
背景
我正在使用美元符号内联分隔符在浏览器上呈现数学。
这会导致诸如 500$ + 200$
之类的文本出现问题,该文本与 MathJax 语法匹配并呈现为数学。避免将非数学内容呈现为数学内容的常用推荐方法是启用 processEscapes。
MathJax = {
tex: {
inlineMath: [ ["$", "$"] ],
processEscapes: true,
},
};
问题
转义方法需要重写所有非数学语法的内容。之前的 500$ + 200$
变为 500\$ + 200\$
。这不是一个理想的解决方案,因为大多数内容都不是数学重的。当内容包含大量代码时情况会更糟。
这是一个编码问题,我不想将其传递给内容作者。
一个简单的改进是期望所有内联数学内容都是 $tidy like this$
,其中表达式周围没有空格。 Obsidian 和可能的其他 Markdown 编辑器似乎都在遵循这种模式,尽管它仍然存在陷阱。
// This doesn't work, is there a similar approach that works?
inlineMath: [ [/\$(?=[^\s])/, /(?<=[^\s])\$/] ]
这确实是我用来在页面上启用/禁用数学渲染的分隔符表达式,如 MathJax 推荐。该问题发生在 MathJax 解析整个页面的混合内容上。
我尝试过/考虑过的
1. 使用分隔符集 [" $", "$ "], [" $", "$"], ["$", "$ "]
- 这不起作用。
- 这会消耗表达式周围的空间。它们可以用 CSS 添加回来。
- 在很多边缘情况下,分隔内容的顺序和执行顺序将决定解析器将选择什么。
2.自己解析内容,将每个匹配的表达式分别发送到MathJax
- 这可行。
- 是否已经为此构建了解析器?
3. 动态添加转义斜杠
- 这可行。
- 是否有任何现有的东西可以在构建、服务器或浏览器上执行此操作?
Can I instruct MathJax to accept more than a basic delimiter pair?
Background
I am using the dollar sign inline delimiter for rendering math on a browser.
This causes problems for text such as 500$ + 200$
which matches the MathJax syntax and gets rendered as math. The commonly recommended approach to avoiding non-math content being rendered as math is to enable processEscapes
.
MathJax = {
tex: {
inlineMath: [ ["quot;, "quot;] ],
processEscapes: true,
},
};
Problem
The escaping method requires rewriting all content that is not math syntax. Previous 500$ + 200$
becomes 500\$ + 200\$
. This is not an ideal solution where most content is not math heavy. It is worse when content is code heavy.
This is a coding problem that I would rather not pass onto content authors.
A simple improvement will be to expect all inline math content to be $tidy like this$
, where there is no white-space around the expression. Obsidian and possibly other markdown editors seem to be following this pattern even though it still has it pitfalls.
// This doesn't work, is there a similar approach that works?
inlineMath: [ [/\$(?=[^\s])/, /(?<=[^\s])\$/] ]
This is indeed the delimiter expression I use to enable/disable math rendering on a page basis, as recommended by MathJax. The problem occurs on mixed content where MathJax parses the whole page.
What I have tried / considered
1. Use the set of delimiters [" $", "$ "], [" $", "$"], ["$", "$ "]
- This does not work.
- This consumes the spaces around the expression. They can be added back with CSS.
- There are quite a few edge cases where the order of delimited content and order of execution will determine what the parser will pick.
2. Parse the content myself, send each matched expression to MathJax separately
- This works.
- Is there a parser already built for this?
3. Add escaping slashes on the fly
- This works.
- Is there anything existing that does this on build, server or browser?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这是一个配置,允许您为您提供的分隔符指定模式(同时仍然处理您不提供模式的分隔符)。模式必须与数组前两个条目中给定的分隔符匹配,但您的情况就是如此,因此这对您来说应该不是问题。 (更通用的解决方案是可能的,但需要更多您不需要的工作。)
在这里,我们对 FindTeX 类进行子类化,并重写保存分隔符匹配数据的方法。它检查是否给出了模式,如果是,则使用这些模式匹配而不是原始字符串(尽管仍然需要这些模式,以便让开始分隔符能够找到结束分隔符信息,并进行正确的匹配)关闭分隔符处理)。
我认为这将满足您的需求。它可以被制作成更正式的扩展,但由于它相对较短,因此您可以相当轻松地以这种方式使用它。
Here is a configuration that will allow you to specify patterns for the delimiters that you provide (while still handling delimiters where you don't supply patterns). The patterns must match the delimiters given in the first two entries of the array, but that is the case for your situation, so it should not be a problem for you. (A more general solution would be possible, but would require more work that you didn't need.)
Here, we subclass the
FindTeX
class and override the method that saves the data for delimiter matching. It checks to see if the patterns are given, and if so, uses those for pattern matching rather than the original strings (though those are still needed in order to have the opening delimiter be able to locate the closing-delimiter information, and for proper close-delimiter processing).I think this will do what you are looking for. It could be made into a more formal extension, but since it is relatively short, you can use it this way reasonably easily.