When is a cap height not a cap height?

Simon Cozens

I was just on the point of writing some QA tests to ensure that glyphs' points which should be on the baseline/xheight/capheight were actually at the appropriate Y coordinates  - allowing for overshoots, but flagging points which fall one or two units either side of the metric as a potential mistake.

To test my tests, I reached for a copy of Source Sans Pro in order to modify it. But I found that the Y-coordinates of the cap points in Source Sans weren't at the OS/2 sCapHeight metric anyway: sCapHeight is defined as 660, but the top of the capital A, B, D, E, etc. were all aligned to Y=656.

Is this common? Is it a mistake? Why would you define a cap height metric and then not put your caps on the cap height?

Georg Seifert

Have you checked all masters. Maybe the sCapHeight was synced between them?

Simon Cozens

Ah, you're right:

$ for i in *tf; ttx -o - -t "OS/2" $i 2>/dev/null | grep sCapHeight
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>
    <sCapHeight value="660"/>

And indeed the Y-coordinates of the capitals on the Extra Light instance do fall on Y=660. Interesting! So should we regard the OS/2 metrics as family metrics, not font metrics?

Hrant Հրանդ Փափազեան Papazian

Source Serif has actually serious vertical-proportion issues...