Replace mathjax with unicode, where appropriate

[schanzer]

• [x] @math{a} → 𝑎
• [x] @math{b} → 𝑏
• [x] @math{c} → 𝑐
• [x] @math{f} → 𝑓
• [x] @math{g} → 𝑔
• [x] @math{h} → ℎ
• [x] @math{r} → 𝑟
• [x] @math{x} → 𝑥
• [x] @math{y} → 𝑦
• [x] @math{R^2} → 𝑅²
• [x] @math{x_1} → 𝑥₁
• [x] @math{y_1} → 𝑦₁
• [x] @math{x_2} → 𝑥₂
• [x] @math{y_2} → 𝑦₂
• [x] Transliterate expressions consisting only of numbers, =, +, -, >, <, the letters listed above, \mul and \div, simple square roots, and parentheses.
• [x] All fractions of the form \frac{numbers-and-letters}{numbers-and-letters} → \1 \\u2044 \2 (see this reference)

(add more as we go -- possibly extend @math processing to use this, so that we lean on mathjax IFF we can't translate 100% of the symbols with unicode)

[ds26gte]

I just pushed a fix for #1502 whereby mathjax via @math in the ruby part of @fitbruby now works.

I'm just a little bit worried that replacing mathjax with Unicode, while OK for the HTML pages, may not render in the PDF (print version), because print fonts' support for arbitrary Unicode chars is not so good.

[ds26gte]

It may be easier to devise heuristics for when a math expression cannot be Unicoded. E.g., it can't if it

• contains \mbox{...}
• contains \over
• contains \frac with non-simple numerator or denominator
• contains \sqrt with non-simple arg
• contains ^ or _ with non-simple affix

Everything else to be Unicoded. I'm basing this pretty simple 5-part heuristic based on looking at all the @math calls currently in the lessons. If I'm being too simplistic, let me know.

Actually, I'm not sure about the \mbox{...}. They may be convertible to straight HTML (preferably in sans-serif font, so they remain distinguishable from surrounding non-math text. Remainder: we typically use (or should use) \mbox{...} when we have multi-character identifiers that should be treated as kerned units, and not as algebraic juxtapositions).

This issue requires quite a bit of aesthetic consensus. Things should be readable easily, and authors should weigh in based on their own experience with reading mathematical prose and opinions developed.

[schanzer]

@ds26gte I think the heuristic is great!! I think we can encode mbox's as straight html as well.

[flannery-denny]

• [x] translate-arithmetic-to-circles-and-code-challenge-2.pdf Note the curly braces in the last expression

• [x] translate-coe-to-code-w-sqrts.pdf Can radical 4 get a "roof" like longer radical expressions do?

  

• [x] function-composition-scale-xy.pdf arrows have become greater than signs in some contracts

  

• [x] notes-defining-values.pdf another strange radical formatting

  

• [x] match-contracts-examples2.pdf

  

• [x] topdown-bottomup-discussion.pdf the first set of fractions don't render as vertical

  

Noting that the issues I've cited impact more pages than the examples I selected.

[schanzer]

@ds26gte Unsurprisingly, Early Math has fewer errors because it doesn't stretch our math generation code as far as the other classes. Still, a few glitches popped up:

• [x] translating.pdf question 3 is translating a division expression into a fraction
• [x] associativity-makes-comp-easier-challenge.pdf the first box isn't using unicode super/sub to draw a good-looking fractions
• [x] multiplicative-inverse.pdf (and other pages in this lesson!) lots of fractions not using unicode super/sub to draw fractions

[ds26gte]

The fractions not using unicode super/sub could be because you changed the number font? I'm using the suggested U+2044 character for the fraction solidus.

[schanzer]

@flannery-denny Dorai has pushed an update that fixes a lot of the issues you and I were seeing with fractions and radicals. I've inspected all of the errors and checked off the ones that are fixed. If you have bandwidth to review the OK workbook after rebuilding today, that would be terrific.

I was not able to replicate the "arrows without lines" issue you saw. What is the issue with match-contracts-examples? That doesn't have any math in it, and it looks right to me.

[flannery-denny]

@schanzer Just rebuilt and the arrow issue persists in my new workbook.

• In my build all of the contracts that were made with code like this @show{(contract 'ellipse '("Number" "Number" "String" "String") "Image")} have arrows without lines... this impacts a LOT of pages!
• In the match-contract-examples screenshot I was surprised to see 3 * outside of parentheses, but maybe it's fine?

[ds26gte]

-> becoming > does seem like it could be a font issue? Still, surprised that the other macOS user (@schanzer) is not seeing it. You two should zoom it out.

[schanzer]

@flannery-denny even in the exact page you wrote about, I'm just not seeing the broken arrows:

Let me know if you're free to zoom after 10:30am?

[flannery-denny]

If the arrow issue isn’t an issue on your computer, and you’re the one deploying, does that mean it will look right on the web?

[schanzer]

@ds26gte Flannery and I zoomed, and I had a chance to better-understand the issue. It turns out that this IS happening for me too! The arrow is drawn correctly on the web page, and any attempt to manually print the page to a PDF works great. But when puppeteer prints it, the dash disappears!

Are you able to replicate this on your machine? (Again, check the PDF - not the html)

[schanzer]

@ds26gte any way to use a different dash to distinguish negation from subtraction?

We also generate extra spaces that aren't needed (though I get why the implementation does it). Unfortunately, these spaces leak into the HTML and make the output look weird. These screenshots are from "Translate Arithmetic to Circles of Evaluation & Code (Intro)" in order-of-operations.

[ds26gte]

• Fixed the spaces adjacent to parens.

• Neither in math typography nor in Unicode is there any glyph differentiation between unary and binary minus. They are differentiated by kerning only: The binary minus has flanking spaces, while the unary has no succeeding space. For cases where a binary minus is immediately followed by a unary minus, I used to parenthesize the second expression so we don't have a "minus minus" situation, but I was told not to.

[schanzer]

Thanks for rocking the spaces, @ds26gte

Huh - I didn't realize that the typographical precedent for math is that they use the same symbol! I was sort of thinking this would use emdashes (subtract) and endashes (negate). I guess we should go with convention here.

@flannery-denny , I just went through the OK workbook after some sleep and it's looking pretty good. Given that the stuff on the web is pretty broken (contract arrows missing dashes, mathjax failures, etc) think I'm going to just deploy this morning. It would still REALLY help to get the final go-ahead from you before closing this issue, however.

If you see things that need fixing unrelated to math, either make a new issue or dive in and fix them on your own.

[flannery-denny]

@schanzer I’m glad unicode doesn’t distinguish between negation and subtraction! I avoid materials that do because I think it’s critical that students learn to think more fluidly and distinguish based on context!

Consider -5(3 - 8)

You’d probably read it as “Negative five times the quantity three minus eight”

But, when distributing, I end up multiplying “negative 5 times negative 8”

[flannery-denny]

Great work!