Caps taller than ascender

Nick Shinn
Nick Shinn Posts: 2,229
in Font Technology
Is this an issue when entering values in FontLab for “Most important font dimensions”?
Tagged:

Comments

  • Thomas Phinney
    Thomas Phinney Posts: 2,929
    edited March 2017
    Hmmm. I would be inclined to use the taller of ascender or cap height for that purpose.

    That said, I would *love* to hear in what obscure things/places you and your customers encountered problems, after you stuck with the literal typo values in the right places. Even then, I would use the higher value for TypoAscender—I think that is effectively the spirit of the meaning of that field. Maybe?
  • John Hudson
    John Hudson Posts: 3,277
    edited March 2017
    Hang on a minute, Thomas. I don't think Nick was talking about the OS/2 TypoAscender value, but rather about the FL values that correspond to Type 1 record for ascender, cap, x-height, and descender. These don't necessarily correspond to the OS/2 metrics.

    Nick, I always set those values to actual heights of specific Latin letters:

    ascender = top of d
    cap height = top of H
    x-height = top of x
    descender = bottom p

    But the OS/2 TypoAscender and TypoDescender I set proportionally to the ascender and descender, but summing to the UPM value. This typically means the OS/2 metrics are larger than the actual letter heights.
  • Kent Lew
    Kent Lew Posts: 960
    Hmm. Since those are essentially the old Type 1 values, I always sum the ascender + |descender| to the UPM, just like we used to do.

    I assume the Caps height and x height values get compiled to the OS/2 sCapHeight and sxHeight fields. But the ascender and descender don’t get compiled anywhere in an OpenType font anymore, right?

    Aren’t those two values just used internally by the design environment as the “slug line”s ?

Categories