Label point sizes appear visually different despite being set to the same size in Style

[kai-qu]

I made some simple examples that Keenan requested for the Penrose blog post / Twitter thread, but am running into a weird font size issue.

@maxkrieger @wodeni can you take a quick look and let me know how to address this ASAP, or if there's a (reasonably principled) workaround? It's blocking us from posting examples :)

Repro with minimal example: on branch set-example, do runpenrose set-theory-domain/intersection-venn-diagram.sub set-theory-domain/venn-simple.sty set-theory-domain/setTheory.dsl

Expected result: all labels have the same size, 15 pt

Actual result: "Circle" label looks smaller than the other two

Tried:

• changing the label size in Style (seems to actually set the label size)
• running examples with other Styles ("Circle" seems to be consistently mis-sized across Style programs)
• looking at DOM (svg indeed has fontSize set to the style size, but changing it in chrome does not change the font size live, as noted in Computing label dimensions reliably #301 (comment))
• changing the label text (I can't consistently repro the mis-sizing, e.g. if I change the labels to strings of different sizes, like "Z", "ZZZZ", and "ZZZ ZZZ ZZZZ", the "Z"s all appear the same size, so I'm not sure if it's an aspect ratio problem)

I also don't know if all three labels are actually mis-sized, but only "Circle" is the visually noticeable one.

Related issues: #301 (comment)

[kai-qu]

Actually, if I set the height of the label to be constant, it seems to look right:

Resolved for my immediate purposes, but definitely unintuitive to a user

[maxkrieger]

this is so weird. Do you think this is a regression from prior behavior or a latent bug? It's possible that it's MathJax3 behaving differently than 2. One way to test this is comparing to this commit, the last one before we added MathJax3: 3f077d9

(I really need to learn how git bisect works. Ive been using git checkout to do this manually)

[kai-qu]

I thought the font sizes had misbehaved in the past (as in the bottom of this comment: https://github.com/penrose/TOG-2019/issues/5#issuecomment-546659288), but I don't remember if that was an actual issue or an optical illusion.

[maxkrieger]

optical illusions: #JustPenroseBugTypes

[maxkrieger]

For future use.

[kai-qu]

Lol. Anyway, unfortunately setting the label height behaves poorly in the tree example:

runpenrose set-theory-domain/intersection-venn-diagram.sub set-theory-domain/tree.sty set-theory-domain/setTheory.dsl

1. inconsistent sizes with fontSize: "12pt"
   

2. label dimensions seem to be ignored with h : 50.0, even though the bbox is properly sized

3. behaves as expected with h : 25.0

Not sure what's going on with the first two.

[kai-qu]

(Updated above comment to reflect that I resolved the unrelated padding issue)

[maxkrieger]

Speculation: our "output container" is ill-defined: http://docs.mathjax.org/en/latest/web/typeset.html#obtaining-the-output-metrics

We aren't doing stuff in the DOM, we're rendering the label headlessly and then placing it, absolutely-positioned and relatively-sized, in a custom layout engine. This makes MathJax's job very hard since it has so many assumptions about how text will be situated.

Hypothesis: in absolute terms, $X$ will be bigger, unconstrained by containers, than $\text{lorem ipsum dolor sit amet}$, since $X$ is easier to "scale to fit" an infinite height, fixed width container.

I don't think there's a quick fix for this :( unless @wodeni has hack ideas

[maxkrieger]

Tldr: what I grok from MathJax is that it sorta listens to font size but not really because translating that into concrete path dimensions is complicated ??

[kai-qu]

Sounds complicated. Thanks for looking into this!

[maxkrieger]

@wodeni just defer to this thingy and maybe it works https://github.com/mathjax/MathJax-demos-web/blob/master/input-tex2svg.html#L35-L37

[maxkrieger]

Nimo's other hypothesis: the g's descender makes the height bigger

[maxkrieger]

http://docs.mathjax.org/en/latest/options/output/index.html#output-options

http://docs.mathjax.org/en/latest/misc/faq.html#some-of-my-mathematics-is-too-large-or-too-small-how-do-i-get-it-right

[maxkrieger]

https://github.com/penrose/penrose/blob/master/react-renderer/src/utills/CollectLabels.tsx#L20

Edit to: http://docs.mathjax.org/en/latest/options/output/svg.html#the-configuration-block

[kai-qu]

some helpful comments from the MathJax folks: mathjax/MathJax#2437 (comment)

[maxkrieger]

I think I have a heuristic that fixes it for now (ignore my bad hand-alignment):

(without height-translation correction on verticalAlign)

(with)

I followed the maintainer's advice and corrected the height according to the ex value of the vertical-align style on the SVG outputted by MathJax. I rescaled the ex to the (internally consistent) coordinate space of the viewBox outputted by said SVG. More details self-explained by this code https://github.com/mathjax/MathJax-src/blob/32213009962a887e262d9930adcfb468da4967ce/ts/output/svg.ts#L248

(in web-runtime branch)

Note the use of constant height: @wodeni, we may not be able to do "fancy" units headlessly (see how LiteAdaptor - MathJax's virtual dom - handles this https://github.com/mathjax/MathJax-src/blob/32213009962a887e262d9930adcfb468da4967ce/ts/adaptors/liteAdaptor.ts#L43) but we sure can do internal/pixel heights!!

[kai-qu]

@maxkrieger That new screenshot looks great! So, in practice, how should we be setting label sizes in the future in Style? Still something like fontSize: "12pt" or is it pixels only?

Also, can you confirm that your new changes don't break anything on the existing working examples for web-runtime? (i.e. just run each of them and check that things look fine)

[maxkrieger]

So, in practice, how should we be setting label sizes in the future in Style? Still something like fontSize: "12pt" or is it pixels only?

For now pixels only, until the maintainer gives a solution. We can also do our own heuristic and internally set the pixel values to match the unit's. Curious what @keenancrane thinks about these non-pixel units in the long run. I know it makes embedding in papers way easier (matching the global font) but I'm guessing that the relation to the shapes (which use pixel values) is important too?

Also, can you confirm that your new changes don't break anything on the existing working examples for web-runtime? (i.e. just run each of them and check that things look fine)

Done! ✅ lgtm (not much different). Continuousmap currently throws an error but it was this way before my changes.