Skip to main content
_
_ASeidel_
Known Participant
May 1, 2003
Question

setup of usWinAscent & usWinDescent

  • May 1, 2003
  • 4 replies
  • 2202 views
Hello,

Fontvalidator sugguest to set hhea.Ascender and OS/2.usWinAscent to the
same value.

How can I do this?

table OS/2 {
TypoAscender 701;
usWinAscent 701; # not working
TypoDescender -299;
usWinDescent -299; # not working
XHeight 576;
CapHeight 717;
} OS/2;


Andreas
This topic has been closed for replies.

4 replies

_
_Read_Roberts_
Inspiring
May 19, 2003
Sorry to take so long to answer. The question fell into that awkward area between " answerable in less than 10 minutes" and " so long that I need to schedule it".

You cannot currently override the OS2/usWinAscent without changing glyphs. MakeOTF sets the usWinAscent to the top of the font global bounding box. It ignores the font BBOX def:
/FontBBox {-350 -299 3884 701} readonly def
as this is bad data in many fonts.Instead, it calculates the actual global font BBox by looking at the max values for any glyph in the font.

Note that you do not necessarily want the usWinAscent/Descent to be the same as usTypoAscent/Descent. The latter must sum to the em-square, the former do not. (although I do not know enough to tell you why)

If there is no OS/2 CapHeight override, it is set to:
top of uppercase O, with overshoot removed, e.g
glyph O bbox top - bbox bottom.

If there is no OS/2 XHeight override, it is set to:
top of lowercase o, with overshoot removed, e.g
glyph o bbox top - bbox bottom.

OS2-usWinAscent is first set to the top of the global font bounding box , and OS2-winDescent is set to the bottom of the global font bounding box. Howver, if the span of the two is greater than the emsquare size, then the usWinAscent is truncated so that they sum to the em-square.

If there is no OS/2 TypoAscender override. MakeOTF uses the larger of the bbox height of 'd' or the font Cap Height, as calculated above.

If there is no OS/2 table override for TypoDescender, MakeOTF uses (em-square size - OS/2 TypoAscender)
The two values must sum to the em-square size.

If there is no OS/2 override for typoLinegap, it is set to:
EM_SCALE(1200) (TypoAscender + TypoDescender).

These rules were worked out so that the font metrics and lconsequent ayout of text as reported via the Windows GDi and the Mac OS 9 Font Manager would be the same.
T
Thomas Phinney
Inspiring
May 6, 2003
Huh. Maybe Read can tell us something....
_
_ASeidel_Author
Known Participant
May 13, 2003
Thomas Phinney wrote:
>
> Huh. Maybe Read can tell us something....


Dear Read,

do you so kind to comment this problem?
T
Thomas Phinney
Inspiring
May 4, 2003
I believe that what you'd need to edit would be the already existing FontBBox entry in the .pfa.

T
_
_ASeidel_Author
Known Participant
May 5, 2003
Thomas Phinney wrote:
>
> I believe that what you'd need to edit would be the already existing FontBBox entry in the .pfa.
>
> T

OK Thomas,

so it is a bug of MakeOTF? Because my fontbox settings are right.

/FontBBox {-350 -299 3884 701} readonly def

MakeOTF generates different values - why?

hhea.Ascender = 701, OS/2.usWinAscent = 754
hhea.Descender = -299, OS/2.usWinDescent = 303




Andreas
_
_ASeidel_Author
Known Participant
May 14, 2003
Andreas Seidel wrote:
>
> Thomas Phinney wrote:
> >
> > I believe that what you'd need to edit would be the already existing FontBBox entry in the .pfa.
> >
> > T
>
> OK Thomas,
>
> so it is a bug of MakeOTF? Because my fontbox settings are right.
>
> /FontBBox {-350 -299 3884 701} readonly def
>
> MakeOTF generates different values - why?
>
> hhea.Ascender = 701, OS/2.usWinAscent = 754
> hhea.Descender = -299, OS/2.usWinDescent = 303
>
> Andreas


Maybe this issue is related to the fact MAKEOTF generates an OS2 table
revision 2 not 3?

Should I edit the values with an table editor to avoid the problem of
different line highs between Apple OS & Windows? Or this problem only
appears on TrueType flavored OpenType Fonts?

Please Read help!

Andreas
_
_Antoine_Picard_
Participating Frequently
May 1, 2003
the usWinAscent/Descent values come from the bounding box that's stored in the source font.

Therefore, you can either modify your source font or your OS/2 overrides to match but you cannot override usWinAscent/Descent using the features file.

Antoine
_
_ASeidel_Author
Known Participant
May 2, 2003
Antoine Picard wrote:
>
> the usWinAscent/Descent values come from the bounding box that's stored in the source font.
>
> Therefore, you can either modify your source font or your OS/2 overrides to match but you cannot override usWinAscent/Descent using the features file.
>
> Antoine

thank you Antoine,

but the problem is, usWinAscent/Descent will not be stored as values (or
editable values) in a *.pfa file.

Its possible to add it by hand like:


/WinAscent 701 def
/WinDescent -299 def

If yes, on what place exactly?


Andreas
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices