When is a cap height not a cap height?

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?

Comments

  • Have you checked all masters. Maybe the sCapHeight was synced between them?
  • 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?

  • Source Serif has actually serious vertical-proportion issues...
Sign In or Register to comment.