Rules can be set to any arbitrary height. This should be tested with some really tall ones. I haven't got time to test this myself this myself at the moment, but when I was working on PR #670, I ran into trouble when I tried to accommodate tall images by a method similar to this.

If I recall correctly, makeVList applied the maxFontSize not only to the element that needed it, but to all the members of the vlist. I ended up in some cases with unexpectedly large spacing above the vlist. I.e., the vlist pushed the whole line downward on the screen and left a large gap above the math.

For \fbox, my solution was to (1) set maxFontSize to 1 em because that did not distort the rest of the vlist, and (2) adjust the position of the fbox after running makeVList. The adjustment looks like:

if (img.height > vlist.maxFontSize) {
        // Correct for an issue in makeVList. It placed the image top at
        // the top of the line box created by a 1 em maxFontSize.
        vlist.children[1].style.top = -(inner.height + pad - 0.9 / scale)
            + "em";
        // The 0.9 in the previous line is there because the KaTeX fonts
        // have an ascent = 0.9 em. We're setting the top of the image
        // relative to the top of that line box.
    }

Just a suggestion.

Hi @ronkok, that doesn't work when sizes change, even for \fbox. E.g. (on master):

Or (again on master) try \fbox{\rule{0.1em}{2em}}.

The fontsize-ensurer nodes are weird and suboptimal, but given the current CSS coding they appear necessary.

I think this commit should be merged (I've tested with very large rules—thanks!—and they work, although they do, as you suspected, introduce large gaps) and the vlist/fontsize-ensurer issues pushed to another project.

@kohler, Thank you for pointing out the issue with a size change inside an fbox. It looks like I have more work to do. Sigh.

Maybe it would be good to add some more test(s) to illustrate, such as the \fbox{\huge} example and large \rules?

I'd like this PR to concentrate on bug #646, and there could be another PR or issue on issues surrounding fontsize-ensurer?

@kohler could you post a screenshot of \frac{\textcolor{blue}{\rule{2em}{2em}}}{2} from the original issue?

Curious got the better of me. It'd be good to have this as a screenshot test as it's more obvious what the problem is in this example as compared to the existing screenshots that change.

One concern I have about adding more screenshot tests is that the tests and taking longer and longer to run. I hope that the new headless modes for Chrome and Firefox will make it easier to take screenshots.

Screenshotter test added. Re: test speed, PR #752 speeds up screenshotter tests 6x