You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the example article I have used various directives, e.g. theorem, proposition, etc (see https://mystmd.org/guide/proofs-and-theorems). The directives do not appear in the Latex/Tex file.
Note: the Springer templates uses special tex environments for theorem, proposition, etc. The question is how can we make sure that the Myst Build process uses those environments.
The text was updated successfully, but these errors were encountered:
yes, currently the proof and theorems have no specific export to latex defined and so are omitted. These should have latex translations added and that then leads to the question of what should be the standard form of those and how does that relate to this template.
Supporting base proof and theorem environments seems sensible as it enables the templates to define their handling, it probably gets more sticky when looking at the specific options a template supports and choosing those to be broadly applicable. If there is a lot of variation that could be difficult.
I would suggest the following. Myst currently supports the directives as specified here: https://mystmd.org/guide/proofs-and-theorems. The default behavior, in my opinion, should be to translate this to:
\begin{directive-name}
\end{directive-name}
In case of a theorem this would read:
\begin{theorem}
\end{theorem}
However, to allow more flexibility and to support further options a template author should be able to override the default translation using an entry in template.yml. I could imagine that this could look like this:
In the example article I have used various directives, e.g. theorem, proposition, etc (see https://mystmd.org/guide/proofs-and-theorems). The directives do not appear in the Latex/Tex file.
Note: the Springer templates uses special tex environments for
theorem
,proposition
, etc. The question is how can we make sure that the Myst Build process uses those environments.The text was updated successfully, but these errors were encountered: