-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Converting a paragraph containing an equation from org to latex results in 3 paragraphs #10836
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
Comments
Notice this difference:
Potential solution: have the org reader handle the equation environment like the latex reader does, treating it as regular display math. This would facilitate conversion to many formats besides LaTeX. However, it would mean losing the equation number on export to LaTeX. |
A different solution would be to parse the equation environment as RawInline rather than RawBlock. |
For me personally losing the equation numbers would be a defeat the reason to use equations at all. Might as well use inline math at that point, if I cannot properly reference it. I'm guessing it would be fine for \begin{math} environment, because that isn't numbered. But I don't use that environment, so I don't know. I'm guessing you don't want your codebase polluted with sed -e 's \\end{subequations} \\end{subequations}\n\\noindent{}\\ignorespaces g' file.org | pandoc -o file.tex (same with normal equations) This does not get rid of the paragraphs, but the reader won't notice because the paragraphs just look like newlines or at least aren't indented. The |
Yikes sorry, I accidentally closed it. I'm a github noob.
Regarding this, I don't know what that would mean. I'm not similar with the codebase, sorry. |
If you want something without sed, you could put something in Making it a RawInline would case the environment to appear inside the paragraph as part of its contents, which is what you want. So that might be a worth while change, and it's probably not a difficult one. |
OK, I think I've fixed this in a satisfactory way. @tarleb let me know if I've made some blunder. |
Previously inline TeX was handled in a way that was different from org's own export, and that could lead to information loss. This was particularly noticeable for inline math environments such as `equation`. Previously, an `equation` environment starting at the beginning of a line would create a raw block, splitting up the paragraph containing it (see #10836). On the other hand, an `equation` environment not at the beginning of a line would be turned into regular inline elements representing the math. (This would cause the equation number to go missing and in some cases degrade the math formatting.) Now, we parse all of these as raw "latex" inlines, which will be omitted when converting to formats other than LaTeX (and other formats like pandoc's Markdown that allow raw LaTex). Closes #10836.
Previously inline TeX was handled in a way that was different from org's own export, and that could lead to information loss. This was particularly noticeable for inline math environments such as `equation`. Previously, an `equation` environment starting at the beginning of a line would create a raw block, splitting up the paragraph containing it (see #10836). On the other hand, an `equation` environment not at the beginning of a line would be turned into regular inline elements representing the math. (This would cause the equation number to go missing and in some cases degrade the math formatting.) Now, we parse all of these as raw "latex" inlines, which will be omitted when converting to formats other than LaTeX (and other formats like pandoc's Markdown that allow raw LaTex). Closes #10836.
Thanks for the tip! And obviously thanks for fixing it! |
Thanks for the fix, LGTM. I'm slowly catching up on the most pressing tasks, might take me while. |
Previously inline TeX was handled in a way that was different from org's own export, and that could lead to information loss. This was particularly noticeable for inline math environments such as `equation`. Previously, an `equation` environment starting at the beginning of a line would create a raw block, splitting up the paragraph containing it (see jgm#10836). On the other hand, an `equation` environment not at the beginning of a line would be turned into regular inline elements representing the math. (This would cause the equation number to go missing and in some cases degrade the math formatting.) Now, we parse all of these as raw "latex" inlines, which will be omitted when converting to formats other than LaTeX (and other formats like pandoc's Markdown that allow raw LaTex). Closes jgm#10836.
Previously inline TeX was handled in a way that was different from org's own export, and that could lead to information loss. This was particularly noticeable for inline math environments such as `equation`. Previously, an `equation` environment starting at the beginning of a line would create a raw block, splitting up the paragraph containing it (see jgm#10836). On the other hand, an `equation` environment not at the beginning of a line would be turned into regular inline elements representing the math. (This would cause the equation number to go missing and in some cases degrade the math formatting.) Now, we parse all of these as raw "latex" inlines, which will be omitted when converting to formats other than LaTeX (and other formats like pandoc's Markdown that allow raw LaTex). Closes jgm#10836.
Uh oh!
There was an error while loading. Please reload this page.
Problem description
Converting a paragraph containing an equation from org to latex results in 3 paragraphs, because pandoc inserts a newline before and after the equation. For example this org file:
Gets converted to the following latex code:
But if we use emacs' org-mode for the conversion, we get this latex code:
So it should be considered a bug.
You also get the same issue when using the
\begin{subequations}
and\begin{math}
blocks.Pandoc version?
3.6.4
I also tested it in the online version.
Links to similar issues
Markdown had similar issues in the past.
#7883
#3726
#894
#2171
The text was updated successfully, but these errors were encountered: