Typesetting math in defblocks
Nidish96 opened this issue · comments
Firstly great package, thanks a lot!!
While typesetting inline math on org, I usually just use $$ and proceed, and the latex interpreter interprets it as latex math and the html interpreter does the right thing too.
But the following doesn't work:
#+begin_details SDOF equations are $m\ddot{x}=f(t)$
The above is a differential equation with $\ddot{x}$.
#+end_details
Here's the result to this on html :
As you can see, the second math equation works properly, but the first one doesn't.
Is there any easy way to fix this?
Update: delimiting the $
s and /
s I could get the above to work with latex but not with html:
SDOF equations are \$m\\ddot{x}=f(t)\$
yields what is expected on latex.
I'm glad you like the package ❤️
The way that the special blocks work is that their main argument is actually a string literal; it is not generally interpreted as Org markup. As such, if we treat it as a string then we just need to escape the relevant parts:
#+begin_details "SDOF equations are \\(m\\ddot{x}=f(t)\\)"
The above is a differential equation with $\ddot{x}$.
#+end_details
This works and produces, in HTML:
It seems that the above string fact should be better documented. Sorry about that 😅
Thanks for the response (apologies for my delay).
I can confirm that your solution works.
But I found it interesting that the following works,
#+begin_details "SDOF equations are \\(m\\ddot{x}=f(t)\\)"
The above is a differential equation with $\ddot{x}$.
#+end_details
but this does not:
#+begin_details "SDOF equations are \$m\\ddot{x}=f(t)\$"
The above is a differential equation with $\ddot{x}$.
#+end_details
Output of the second version is:
This might just be a minor point, since latex supports both $ eqn $
as well as \( eqn \)
for inline math, but i was just curious if there was any particular reason for this.
but i was just curious if there was any particular reason for this.
@Nidish96 This is because Org needs to see some top-level math before loading MathJax ---see Issue #17 for a MWE Org file that mentions this issue and demonstrates it.