-
Notifications
You must be signed in to change notification settings - Fork 5
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
Allow rich inline content (or OMOBJ) in OMCD texts #20
Comments
I don't think we should allow omobj in cmp, it sort of loses the point of the distinction between CMP and FMP. Many CDs use some kind of pseudo-tex in cmp (and other text areas of CDs) since mathjax is anyway active in the standard display, then with a bit of care and making the pseudo-tex more accurately mathjax-tex, then it will get displayed as math without any changes in the standard text or the implementation. |
In the absence of a compelling use case, I'd agree with David. |
David's citation is not quite summarizing the whole discussion in in the issues cited above. I think that there is a very compelling use case to to be made to use inline HTML5 (maybe only a restricted subset) in CMPs. In particular, having MathML in there would be very helpful. And I would only use the OMOBJ David cites inside MathML parallel markup. Wouldn't it be much nicer to see nice MathML instead of
(adapted from
where There are tools to create this relatively painlessly (for instance my sTeX system). The result here would be that we can have much better-looking CDs that can be made much more active and helpful. I would call this a compelling use case (but not for R2). |
I think I still disagree here: A major point of a CMP is not to need that
kind of structured xml text, if you had written mathjax inline math
delimiters \(..\) in that original cmp with tex markup then mathjax will
display it as math anyway.
Currently actually the Cds don't use mathjax on firefox but that could
easily be switched to always use mathjax if we want it to pick up tex as
well as mathml.
…On 6 October 2017 at 08:26, Michael Kohlhase ***@***.***> wrote:
David's citation is not quite summarizing the whole discussion in in the
issues cited above. I think that there is a very compelling use case to to
be made to use inline HTML5 (maybe only a restricted subset) in CMPs. In
particular, having MathML in there would be very helpful. And I would only
use the OMOBJ David cites inside MathML parallel markup.
Wouldn't it be much nicer to see nice MathML instead of
<CMP>
grad(F) is defined as (\partial(F)/\partial(x_1), ... ,\partial(F)/partial(x_n))
</CMP>
(adapted from veccalc1.ocd). What I am proposing as a best practice is to
show this as
<CMP>
<math>
<semantics>
<mrow>
<mo>grad</mo>
<mo>(</mo>
<mi>F</mi>
<mo>)</mo>
</mrow>
<annotation-xml encoding="OpenMath">
<OMR href="#lhs"/>
</annotation-xml>
</math>
is defined as ....
</CMP>
where lhs is the id on the OM subobject in the accompanying FMP which
represents the left hand side of the defining equation.
There are tools to create this relatively painlessly (for instance my sTeX
system).
The result here would be that we can have much better-looking CDs that can
be made much more active and helpful.
I would call this a compelling use case (but not for R2).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABNcAnZTuBbLN_ck2Z2fZTofmHX8N8uwks5spdY9gaJpZM4Pqop1>
.
|
This is nice in practice, but hardly something our CDs should rely on. I do not consider this a counter-argument. |
On 6 October 2017 at 15:19, Michael Kohlhase ***@***.***> wrote:
This is nice in practice, but hardly something our CDs should rely on. I
do not consider this a counter-argument.
<https://github.com/notifications/unsubscribe-auth/ABNcAqOBQlAFHp1iwlnZJLkBuGt9jpt8ks5spjcKgaJpZM4Pqop1>
Using markup in the CMP would mean that the CDs relied to a far greater
extent on the particular rendering system used. The fact that the CMP do
not do that and can be read even when it's hard to read the FMP which are
fully marked up seems to me to be the main point of having CMP at all.
|
see OpenMath/OM3#145 and OpenMath/OM3#11
The text was updated successfully, but these errors were encountered: