When is a cap height not a cap height?

Simon Cozens
Simon Cozens Posts: 815
in Font Technology
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

  • Georg Seifert
    Georg Seifert Posts: 682
    Have you checked all masters. Maybe the sCapHeight was synced between them?
  • Simon Cozens
    Simon Cozens Posts: 815
    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
    Hrant Հրանդ Փափազեան Papazian Posts: 2,044
    Source Serif has actually serious vertical-proportion issues...

Categories