Is it possible to have a font that is postscript that can have flourishes that go past the cap height. My caps are set at 700 but the largest flourish peaks at 1073. The same flourish also peaks out at -735 below the baseline. Do I have to scale the whole font down so everything fits in the 1000 em unit. I was hoping not too because I am afraid I will get minor distortions from scaling down. The font works fine in adobe products but the flourishes get cut off in word 2007. I am not very familiar with word but when testing it the alternates that have flourishes were all cut off. I am afraid that some customers will complain if they are using word or the basic word program on a mac. Thanks for any info you suggest.
1) Select "Set Custom Values"
2) TypoLineGap and LineGap, both set to 0 (zero)
3) Os2 TypoAscender and TypoDescender: Use your normal metric values
4) hhea Ascender and Descender: Use your normal metric values
5) WinAscent and WinDescent: use 1073 and -735
Or, option 2, use the bbox values for all the 3 groups:
3) Os2 TypoAscender and TypoDescender: 1073 and -735
4) hhea Ascender and Descender: 1073 and -735
5) WinAscent and WinDescent: 1073 and -735
In webfonts we usually go for option 2, to minimize line-height rendering differences between all the different browsers and operative systems and apps.
Also, we usually try to fit the font in bbox values no larger than 25% bigger than the UPM.
So, maybe I will suggest just a little bit of scaling down, so that the sum of WinAscent + WinDescent does not exceeds 1250 units.
1. Set OS/2 WinAscent and WinDescent values to bounding box height and depth.
2. Set TypoAscender and TypeDescender relative to actual ascender and descender measurements, but rounded so that together they sum to the UPM value (both values taken as positive for this calculation).
3. Set TypoLineGap to be the difference between the sum of the TypoAscender and TypoDescender values and the sum of the WinAscent and WinDescent.
4. Copy Typo- values to corresponding hhea metrics.
As Pablo suggests, if you want the linespacing produced by use of the OS/2 Win- values in GDI apps to be no larger than typical default leading (120-124% of body height), then you might need to scale the outlines so that the bounding box is smaller. But scaling will produce outline rounding errors, so I would be wary of doing this if you have substantially completed your design. The relationship of outlines to vertical metrics is, ideally, something you work out at the beginning of the design process.
By setting all the 3 metrics groups to the same values and the linegap to zero, you minimize the chance of inconsistent line-height rendering across devices.
Google have done intensive/obsessive testing on this (in particular to prevent text reflow issues in Google Docs, where the same document can be open/printed by any device under any OS, including phones and tablets) and this is the method they recommended us.
Differing languages and Scripts also want use of different metrics pesented to the app from the same font, if these metrics have not been so compromised, e.g. to have kabonged the Aring to the rest of the accent heights...
So if the app is misbehaving for some other reason, that's one thing forever, and then you have the script language issue, and then there is the ever present forgotten issue of size, where vertical metrics are not best restricted to one size fits all.
Eternal design compromise, via voodoo numbers, or a better font format... Hmmm.
Every time I visit Microsoft, I tell them we should add script and language specific vertical metrics to fonts. The OTL tag system provides everything they'd need in terms of script and language identification: they'd just need a place to add the metrics data associated with the tags. VMTR table anyone?
Voodoo Metrics Type Restrictions?
SIZE matters. This age of NMAE no one nkosw the eanmgni of is getting old., I think. The public is on it's way to the tables.;)
Not with Fontforge http://fontforge.org/faq.html#non-integral
There is also a big question about what the relationship of max and min extent settings should be to linespacing. We already have a massive legacy problem with GDI treating WinAscent and WinDescent extent values as a basis for linespacing, instead of Typo values. One thing we should have learned is that non-clipping bounding box zones should not necessarily correspond to desired default linespacing.
The BASE table could be extended with a format that contains script/lang specific lineheight information then. The cost of implementing a new BASE table format or a brand new VMTR table is practically the same. Whatever it is in the end, I’m all for it, we seriously need this to be implemented.
One extra question: I've seen a number of typefaces where accented characters (e.g. /Egrave) do go above the ascender height. Will something like that result in problems (e.g. in Word)?