Compare latexmath to image math rendering in asciidoctor branch

[oddhack]

This modifies the Asciidoctor HTML & PDF specs to compare asciidoctor latexmath rendering vs. the image approaches previously used. See the
generated HTML / PDF in the Actions artifacts download and search for
"Latexmath" (followed by "Old") versions of each equation.

Relevant points:

• The HTML output is not self-contained. It introduces an external dependency on the MathJax package on a CDN outside our control.
• MathJax runs after the HTML page is loaded and takes noticeable time - initially you will see the raw latex markup, replaced and re-laid-out with the formatted math.
• The PDF output introduces a new dependency on the asciidoctor-mathematical gem (the Khronos Docker image already has this).
• The PDF math rendering quality is noticeably lower than the HTML rendering quality.

[oddhack]

CI-generated HTML/PDF artifacts are here: https://github.com/KhronosGroup/glTF/actions/runs/388291471

[emackey]

This is really cool! The only blemish is the issue of rasterized math on the PDF side, but some of our math was images anyway, and I don't think ISO cares. So on the whole I think this is a big improvement. I'm curious if @donmccurdy or Neil have thoughts on this.

[donmccurdy]

The PDF math rendering quality is noticeably lower than the HTML rendering quality.

I have to say I can't see this difference. If anything, the PDF looks sharper under "latexmath" than under "old" in my PDF viewer (Preview for macOS). I haven't tried comparing on a high-DPI display or anything like that, but the screenshot below is enlarged a bit:

Figure 1: Screenshot of PDF output.

I do see some minor typography issues in the HTML version. It's subtle, and I suspect it's related to choice of fonts and sizes. Notice the small notches on the sides of the bars, here:

Figure 2: Screenshot of HTML output.

Unless you're seeing something significantly different than I am, these don't seem like blocking issues, and the ability to use LaTeX embedded in the specification would certainly be nice.

[oddhack]

The PDF math rendering quality is noticeably lower than the HTML rendering quality.

I have to say I can't see this difference. If anything, the PDF looks sharper under "latexmath" than under "old" in my PDF viewer (Preview for macOS). I haven't tried comparing on a high-DPI display or anything like that, but the screenshot below is enlarged a bit:

Figure 1: Screenshot of PDF output.

Unless you're seeing something significantly different than I am, these don't seem like blocking issues, and the ability to use LaTeX embedded in the specification would certainly be nice.

I'm thinking specifically of the weird matrix brackets with nodules on the top and bottom above. We've run into a few similar issues in the Vulkan spec where PDF math came out with oddly placed or sized symbols, and have lived with it. If the WG likes the latexmath we should just switch over.

[oddhack]

Really the most annoying thing about the builtin MathJax support IMO is the re-layout that occurs after a page is loaded as the math is rendered. For a spec with this little math it's not significant, though noticeable if you have equations visible at the point you load or reload the document. If a lot of math were added over time, the toolchain could be converted to use the same KaTeX / pre-render at document build time approach that Vulkan uses, which is transparent in terms of the markup.

[emackey]

Overall it seems like an improvement. Let's run with it.

[donmccurdy]

Agreed, seems like the right direction, and we can always tweak or optimize rendering later.

[oddhack]

Remove old comparisons and merging per @donmccurdy @emackey