How is a character's height/depth retrieved?

[ghost]

Does WOFF provide native functionality to retrieve what corresponds to height/depth in the TeX box model, given a specific character? If not, how (and where in the source) are these calculated in MathJax? If I’m not mistaken they are necessary information for TeX's layout.

[dpvc]

Currently, there is no API for javascript to get the glyph metrics for a browser font (though there are some proposals for that). So MathJax has the needed data for the characters in its fonts stored in data files that it loads as part of the font data. That is one reason that MathJax only handles specific fonts (one right now, but more on the way later this summer). See the common/fonts files for the base information. The CHTML and SVG output jax add more information that is specific to that output format. The SVG output doesn't actually use fonts, but rather paths generated from the fonts, so svg/fonts adds all the path information into the font data.

[ghost]

Thanks, that’s exactly what I was looking for.

[paeifbnaeufbpae]

As a follow-up on that: what about the TextMetrics object the Canvas API provides with measureText()? It seems like it's widely supported and provides actualBoundingBoxAscent and actualBoundingBoxDescent.

[dpvc]

@paeifbnaeufbpae, that is a nice idea, but the values seem to be in CSS pixels, while MathJax needs sub-pixel accuracy in order to do the layout properly. Also, I suspect that actualBoundingBoxAscent and actualBoundingBoxDescent` are the ascent and decent values of the font being used, which is the same for all characters in the font, but MathJax needs the character-by-character height and depth information for each glyph, not the font-wide ascent and descent. I haven't checked this, but that is what the documentation and the names of these value seem to imply (it is not entirely clear).

[paeifbnaeufbpae]

@paeifbnaeufbpae, that is a nice idea, but the values seem to be in CSS pixels, while MathJax needs sub-pixel accuracy in order to do the layout properly. Also, I suspect that actualBoundingBoxAscent and actualBoundingBoxDescent` are the ascent and decent values of the font being used, which is the same for all characters in the font, but MathJax needs the character-by-character height and depth information for each glyph, not the font-wide ascent and descent. I haven't checked this, but that is what the documentation and the names of these value seem to imply (it is not entirely clear).

Hm... I suspect that you could just artificially scale the text up by 1 / precision (with precision being 1e-3 or something) to get the equivalent of sub-pixel accuracy?

And given that you first need to call the measureText function and pass in a specific string to measure to even get a FontMetrics object, I'd think it does indeed return the text-specific ascent/descent values. (Of course, one would have to measure single characters then and not larger runs of text.)

I guess a quick experiment would answer this question.

[dpvc]

OK, an experiment does seem to show that they are the actual font metrics on a character-by-character basis, and that they use decimal parts of a pixel rather than full pixels. So that does seem useful, and worth looking into.