Options

Caps taller than ascender

Is this an issue when entering values in FontLab for “Most important font dimensions”?
Tagged:

Comments

  • Options
    Thomas PhinneyThomas Phinney Posts: 2,748
    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?
  • Options
    John HudsonJohn Hudson Posts: 2,977
    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.
  • Options
    Kent LewKent Lew Posts: 905
    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 ?
Sign In or Register to comment.