Computing label dimensions reliably

[wodeni]

Related: #299

To generate figures in headless mode, we still need to know the dimensions of the labels at runtime, since we delegate label rendering to MathJax. The current approach gets SVG DOM elements of labels, call getBbox() on a ghost <g> element that wraps each of them, and return the width and height of the SVGRect returned. @maxkrieger and I did some experiments on the label generation & dimensions of the labels. Here's what we know so far:

• The MathJax SVG labels has path strings that is in some random model space, not the screen space, where the y-axis is facing "up". See an example below:

<svg xmlns:xlink="http://www.w3.org/1999/xlink" width="1.764ex" height="2.041ex" viewBox="0 -773.9 759.5 878.8" role="img" focusable="false" xmlns="http://www.w3.org/2000/svg" style="font-size: 19pt">
  <g stroke="none" fill="#000000" stroke-width="0" transform="matrix(1 0 0 -1 0 0)">
    <path stroke-width="1" d="M231 637Q204 637 199 638T194 649Q194 676 205 682Q206 683 335 683Q594 683 608 681Q671 671 713 636T756 544Q756 480 698 429T565 360L555 357Q619 348 660 311T702 219Q702 146 630 78T453 1Q446 0 242 0Q42 0 39 2Q35 5 35 10Q35 17 37 24Q42 43 47 45Q51 46 62 46H68Q95 46 128 49Q142 52 147 61Q150 65 219 339T288 628Q288 635 231 637ZM649 544Q649 574 634 600T585 634Q578 636 493 637Q473 637 451 637T416 636H403Q388 635 384 626Q382 622 352 506Q352 503 351 500L320 374H401Q482 374 494 376Q554 386 601 434T649 544ZM595 229Q595 273 572 302T512 336Q506 337 429 337Q311 337 310 336Q310 334 293 263T258 122L240 52Q240 48 252 48T333 46Q422 46 429 47Q491 54 543 105T595 229Z">
    </path>
  </g>
</svg>

• To get the labels into the screen space, MathJax does some mysterious computation to compute width and height of the labels in ex unit. Which matchs of ratio of the viewBox exactly. In the previous example:
  2.041ex / 1.764ex = 1.1570294785
878.8 / 759.5 = 1.1570770244
• The result of getBbox, however, seems to return a bbox with a different ratio. We did some light experiements by copying the <svg> with ex dimensions with the one with computed bbox dimonsions in the same parent <svg>. The ex version seems to be bigger:

SVGRect {x: 1.1385265588760376, y: 2.9555952548980713, width: 23.44316291809082, height: 22.20760154724121}

22.2 / 23.44 = 0.94

• Setting the fontSize of the <svg> returned by MathJax has an effect of the size of the glyph due to unknown reasons. We don't know how it's computed, nor can we reproduce it by changing fontSize in Chrome inspector.
• Interestingly, the width and height attributes seem to take precedance over fontSize when they are different. For instance, the venn-3d.sty example renders each label with a computed, Penrose-unit width that's proportional to the radius of the circle containinig it. However, the system still applies a 12pt font size on all labels as well. The frontend, in face, applies both properties on the <svg> at runtime, but the width attirbute determines the actual size of the glyph, which made the example magically works.
• There seems to be no generic server-side implementation of getBbox(). If so, computing the precise dimensions of the labels will have to be algorithmetic. However, the transformation from MathJax's label space to the canvas space in the brower (currently done by MathJax) is still unknown, preventing us from computing it by hand.
• For now, we are assuming 12pt for all mass-generated diagrams and use a magic number to convert from ex to px. Due to the abovementioned bbox inaccuracy problem, this number is in face inaccurate (mostly to the precision of 0.1 ish). Things like https://github.com/kapetan/text-height might be useful, but we have not tried these options.

[kai-qu]

Bumping this issue, along with https://github.com/penrose/TOG-2019/issues/8, as if the paper submission is accepted, we would likely need to fix the label dimensions.

[joshsunshine]

Just do it.

[wodeni]

Bumping this issue. For Equation, #1026 standardized dimensions for both node and browser.

However, we introduced Text in #829 and subsequently refined the measurements in #842. There are still discrepancies between node and browser. Some related issues in node-canvas:

• measureText differs significantly from browser implementations Automattic/node-canvas#331
• measureText rounds width value when canvas is built with Pango version >=1.50.0 Automattic/node-canvas#1950

@samestep and I guess that the difference might be in the rasterizers. Leaving this issue open to keep track.

[wodeni]

This is no longer a concern for us because we don't need 100% parity between node and browser for the registry CI task nowadays.