Skip to content
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

\top should have mathclass ord(inary) #83

Closed
fatanassow opened this issue Feb 7, 2016 · 3 comments
Closed

\top should have mathclass ord(inary) #83

fatanassow opened this issue Feb 7, 2016 · 3 comments

Comments

@fatanassow
Copy link

When you render

$\top \otimes t = t$

to MathML, \top outputs as <mo>⊤</mo> (an operator) rather than <mi>⊤</mi> (an identifier). According to Knuth's TeXbook, Appendix F, Section 4(page 435 in my edition), \top has type Ord(inary), so (according to my sketchy understanding of MML) it should output as mi.

You might want to double-check the rest of the macros/symbols in the table on that page as well, such as \bot. In particular, I also noticed that \backslash typesets differently than /, which might be due to the same issue; perhaps it is intended, but MathJax typesets both slashes in the same way. (n.b. \backslash is different from \setminus.)

John's comments:

This is all done by the texmath library (jgm/texmath on
github). I see the following in the table for control
sequences:

       , ("\\top", ESymbol Ord "\x22A4") 

An ESymbol Ord is rendered as an mo element.
We could change this to EIdentifier "\x22A4", and it would
always be an mi. This probably makes sense. You can submit
a bug report on jgm/texmath, so I don't lose track of the
issue.

(There is probably a reason it was ESymbol Ord, but I don't
recall what it was.)

You can submit another issue to support \mathord.

Both of these should be fairly simple changes.

Reference: https://groups.google.com/forum/#!topic/pandoc-discuss/faM55dIJDI0

@fatanassow
Copy link
Author

I checked it and both \bot and \backslash get output as mo, even though they both appear in the Ord table I cited.

@jgm
Copy link
Owner

jgm commented Feb 7, 2016

If all Ord symbols should output as mi, that's a simple
change involving the MathML writer (not the TeX parser).
After all, we're already parsing these as ESymbol Ord.

What is the difference in rendering between mi and mo in
MathML?

+++ Frank Atanassow [Feb 07 16 10:52 ]:

When you render
$\top \otimes t = t$

to MathML, \top outputs as ⊤ (an operator) rather than ⊤ (an
identifier) According to Knuth's TeXbook, Appendix F, Section 4(page
435 in my edition), \top has type Ord(inary), so (according to my
sketchy understanding of MML) it should output as mi

You might want to double-check the rest of the macros/symbols in the
table on that page as well, such as \bot I also noticed that \backslash
typesets differently than "/", which might be due to the same issue;
perhaps that is intended, but MathJax typesets both slashes in the same
way

John's comments:

This is all done by the texmath library (jgm/texmath on
github) I see the following in the table for control
sequences:
  , ("\\top", ESymbol Ord "\x22A4")

An ESymbol Ord is rendered as an mo element
We could change this to EIdentifier "\x22A4", and it would
always be an mi This probably makes sense You can submit
a bug report on jgm/texmath, so I don't lose track of the
issue

(There is probably a reason it was ESymbol Ord, but I don't
recall what it was)

You can submit another issue to support \mathord

Both of these should be fairly simple changes

Reference:
https://groupsgooglecom/forum/#!topic/pandoc-discuss/faM55dIJDI0


Reply to this email directly or [1]view it on GitHub.

References

  1. \top should have mathclass ord(inary) #83

@fatanassow
Copy link
Author

I am no expert, but it does seem to me that Ord should map to mi, while Op, Bin, Rel, Open, Close and Punct should all map to mo, with Rel acquiring somewhat larger spacing than Bin, and Open, Close and Punct having non-symmetric spacing. I am not sure how best to deal with Op. Also, I don't know how much of this spacing needs to be done explicitly via attributes; I suspect renderers do some spacing automatically by examining the content itself.

I think the difference vis-a-vis mi is that mo generally gets extra spacing around it. The interesting question is what happens when you have two mo's in a row -- this is usually pathological. In any case, you can see plainly that \top \otimes x is rendered wrongly by Pandoc/MathML/Firefox when you compare it with TeX or MathJax: there is too much space around \top, because both \top and \otimes both get assigned mo.

Here is what the MathML spec has to say about mi and mo:

https://www.w3.org/TR/MathML3/chapter3.html#presm.mi

An mi element represents a symbolic name or arbitrary text that should be rendered as an identifier. Identifiers can include variables, function names, and symbolic constants. A typical graphical renderer would render an mi element as its content ..., with no extra spacing around it (except spacing associated with neighboring elements).

https://www.w3.org/TR/MathML3/chapter3.html#presm.mo

Typical graphical renderers show all mo elements as the content..., with additional spacing around the element determined by its attributes and further described below.

You may also wish to consult:

http://tex.stackexchange.com/questions/118605/is-there-a-difference-between-bot-and-perp-when-they-are-used-in-exponent

which contrasts TeX \bot and \perp, which render the same modulo spacing, because \bot is Ord while \perp is Rel. The fact that \perp exists suggests strongly that \bot should be treated differently from it, else why distinguish them? And if \bot is mi then so should \top be, since they are related. A similar argument holds for \backslash and \setminus, although they have slightly different glyphs (I think).

Incidentally, if you don't have TeXbook handy, the Ord table I referred to above is reproduced here under "Miscellaneous Symbols":

http://web.ift.uib.no/Teori/KURS/WRK/TeX/symALL.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants