-
Notifications
You must be signed in to change notification settings - Fork 61
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
MD -> LaTeX: gather
is not properly generated
#974
Comments
The document that you are rendering is built in two phases:
Looking at the writer, we acknowledge that we don't yet handle AMS math. I did wonder whether we should flag the AST to indicate that the content is ASMMath, but that would probably require annotating the So, my guess is we might want to just identify AMSMath from the content of the node. In the writer, this would probably be a simple as testing for |
There is a TODO in the writer here: Depending on how deep this goes, we might need to have an update to the tokenizer: |
Sure, some help on this would be good, since this is a show-stopper for trying out
That does seem reasonable. I was thinking for this one, to add another I think the issue here is that |
If you open a PR, we can collaborate on it.
I think we can assume that the contents of the The question will be what to do about the :::{math}
:enumerated: true
\\begin{gather*}
...
\\end{gather*}
::: Because these options are only set if the user explicitly creates a math environment in MyST markdown, and specifies them. We could alternatively ignore them, but I'm somewhat against that. |
:::{math}
:enumerated: true
\\begin{gather*}
...
\\end{gather*}
::: I would say if the user combines Caveat with
As soon as I have any commit to open it with :D.
Thanks for the pointer. That would still be in the |
That should be |
For some background/info on a few of the code-paths at play: When parsing a tex file (no markdown): tex-to-myst --> AST --> transformations --> myst-to-tex When parsing tex AMS environment in a markdown file: markdown-it-amsmath --> myst-parser --> AST --> transformations --> myst-to-tex I think that in this case you are likely writing in markdown? In which case For the labels, we parse those out of the equations so that we can do cross-references, etc. in myst. There is also some handling for sub-equations, with each of their own labels. All of this is done in a transformation on the math node in the AST. |
Hmm, so if |
@LecrisUT I just had a meeting with @rowanc1 where it became clear I think I misunderstood the document type that you're using; I'd thought you were using LaTeX -> LaTeX, but it seems like you're actually reading MyST -> LaTeX. I'm just working on some other PRs at the moment, but I'll circle back around to this shortly. |
It seems to me that we want to include the environment in the math AST node. As such, we also want to support the environment in the math directive e.g.
We already strip out the "basic" environments in https://github.com/executablebooks/mystmd/blob/974dde179c40ff57908b55925baf9212455a16bf/packages/myst-transforms/src/math.ts#L251 I believe we should leave the AMSMath environments because there's no strong push factor to use an alternative. We could lift information about the environment to a new attribute of the math node, but I don't think there's a strong benefit, and presently it would probably complicate things more. It's really a question of "what is math". My proposal is do the simple thing now, and we can "fix" it in future if we realise it was the wrong call. |
Hmm, what about for a temporary fix, inside For a more proper call, the |
Yes, there are two questions here:
I think we should look to fix this as-is, and discuss longer-term AST changes in a new issue :) I think we should try and strip the ASMMath environment so that we can add labels. This makes things more complicated, but is the "right" thing to do imo. |
Wait, I thought the opposite, i.e. strip the |
That's a good point! Hmm. Maybe the proper solution is then to properly parse AMSMath environments into multiple math nodes. But, that's a complex fix. So, for now, let's just pass-through the environment as-is, as you suggest! |
This note is a bit off-topic (in that we should pursue the simple approach suggested in the PR), however, I want to explain some of the previous thinking/work we are trying to put in this direction. There are some changes we made to parsing latex subequations and for align environments to allow these to be picked up and translated to both JATS (used for archiving scientific documents) and the HTML view with basic rendering and cross-references. The challenge in representing this in MyST (and in JATS) is that those environments need to be in charge of the equation labelling and numbering (with specific nodes/attributes for the cross references), and this fights with latex (or at least needs to share understanding). There is actually no way to do a multi-line, labeled subequations in JATS for example, and the way people do it with an and this: The way that I am thinking that we get around that is actually by holding both of these variants in the tree, and we introduced a |
Could :::{mathGroup}
:class: align
x + y & \geq 0
x - y & \leq 4
x \times y & \geq 1
x^y + y^x &\geq 1
::: would generate \begin{align}
x + y & \geq 0 \\
x - y & \leq 4 \\
x \times y & \geq 1 \\
x^y + y^x &\geq 1
\end{align} Not sure how to deal with |
gather
is not properly generatedgather
is not properly generated
Description
Consider the following document:
The issue is that the LaTeX document that it generates becomes:
This should not be surrounded by
equation
blockProposed solution
gathered
vsgather
gathered
vsgather
gather
vsgather*
Then conditionally add either
equation
orequation*
or nothing to the LaTeX documentThe text was updated successfully, but these errors were encountered: