I’ve omitted, for now, some characters because they are HTML reserved characters, or because they need stackrel macros, or because they are of ambiguous atom type or ambiguous name. Omissions include: <, >, :, ⊥, ⊨,|, all triangles, ≔, ≕, ≛, ≝, etc. Follow up on these omissions will come later. So will arrows and negated relations.

Earlier KaTeX efforts toward Unicode input have stalled for fear of future broken content. So I’ve collected some data for use in vetting this work. The following table shows: (1) the KaTeX function to which each character is mapped, (2) confirmation whether unicode math and/or John Cook’s conversion page map it the same way, (3) possible alternates that I did not use.

@ronkok is unicode math in the header of the table mean that you used the unicode-math? (the answer is "yes", I should read comments more carefully 😅). As we start adding support for more characters, I'd like to add a way for us to track which package each mapping is coming from. The reason being is that eventually I'd like for there to be a way to configure which "packages" are active.

I see that you added , true); to a various defineSymbol calls. Does this mean that our existing mapping just happened to line up with unicode-math?

The unicode math link in the third comment is really useful.

This particular PR does have a one-to-one match between unicode math and the KaTeX symbols.js file. In the PRs to come that will often be true but not always. There are some conflicts to come. I omitted any conflicts from this PR. I am trying to submit the easy cases first. After they are out of the way, we can focus attention on the hard cases.

In terms of conflicts I think we should defer to using unicode-math for now. That way whenever we introduce the concept of the "packages" sometime in the future we'll have a consistent situation where all of our unicode chars came from that one package.

When you see all the unicode math choices, I predict that you will disagree with a few of them.

1. A few of their function names conflict with names from other packages, like mathtools.
2. A couple of their names conflict with AMS!

Again, we don't have to settle the hard cases now. That can come later.

Well that's not cool. 😞

Most of the unicode math mappings are good ones. There are just a few head scratchers in there.

Also, here's the data behind John Cook's conversion page.

Wow, thanks for taking this on, @ronkok!

We can add unicode-math to #793 (which I or one of us should turn into a contrib file so that relevant PRs can easily add to it).

The most recent commit fixes a brain cramp of mine. After going to the trouble to create a table that documents a good mapping, the script I used to edit symbols.js then made its selection from column 1 instead of from column 3 of the table.

Fixed now.

@ronkok thanks for the PR.