The 'Ahem' Font

Same! Appears to be some more info/usage here:

https://github.com/Hydrock/AhemFont

I suppose you use it when you're adjusting things to "look right" and need to know how big the character space actually is (then you replace it with the real font you want to use)?

For writing portable, reliable tests for web browsers.

> The web-platform-tests project is a cross-browser test suite for the Web-platform stack. Writing tests in a way that allows them to be run in all browsers gives browser projects confidence that they are shipping software which is compatible with other implementations, and that later implementations will be compatible with their implementations.

https://web-platform-tests.org/

> Tests should be as cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. ... Fonts cannot be relied on to be either installed or to have specific metrics. As such, in most cases when a known font is needed, Ahem should be used and loaded as a web font. In other cases, @font-face should be used.

https://web-platform-tests.org/writing-tests/general-guideli...

Production-quality fonts usually have huge amounts of tweaks and fine-tuning to make them look good. Characters won’t be exactly the same height, they’ll be a bit above or below their nominal position, that sort of thing. Those tweaks also make those fonts completely useless as reference for developers.

What this font gives you is a bunch of boxes and lines with well-defined, predictable sizes and positions, which makes it very easy to validate that your text rendering/layout is at least somewhat sane.

It’s specifically for browsers to use in testing. The idea is that the glyph dimensions and positions fall exactly on pixel boundaries. Then you can make your css, html, SVG, etc test such that you can go through the spec and precisely specify the exact pixel value for an entire test output.

The ideal result is that each engine is able to render the same test and verify that their layout, etc is exactly correct.

Presumably because browser were historically much better at handling and rendering English and Western European characters (and input) than they were at other scripts?

The characters are selected because they possess specific characteristics that make them ideal to handle various cases.

p possesses maximum "descent" for a character (the bit below the baseline on a font).

É not only meets the traditional "ascent" but exceeds it since diacritics normally extend past the traditional ascent on a capitalized letter.

These aren't the only characters that possess these values (although, I assume some selected code points are unique), but just ones that do.

Noto maybe?