I am modifying a font that was published using the Open Font Licence.

So I save the existing font under a different name, open it using FontForge, and start working on it. Change the "f" just to check that everything is working OK, change the metadata so that when I install the modified font it won't want to install over the original, save, generate font, right-click to install. Open MS Word, write a word containing an "f". Check. It's the new "f". Fine.

But then I notice that the descenders are getting cropped. I don't see any reason for this, since with the original font they aren't, and I haven't modified any glyphs that have descenders, or fiddled with the em height, etc.

I've read that Windows 10 can be a bit glitchy in this department and perhaps FontForge can as well. So under Font Information | General I reduce the ascent height by 200 from 1638 to 1438 and increase the descent height by 200 from 410 to 610, leaving the em size unchanged at 2048. This is OK because I plan for my descenders to be long anyway, and there's also height at the top. This all looks great in the glyph table - all the glyphs rise a bit and I can now see the bottoms of all the descenders. OK, so save, generate fonts, install.

But - argh! The descenders are still getting cropped as before, and when I open the modified font again with FontForge the ascent and descent heights have changed back again to 1638 and 410.

How can I change these settings and leave them changed? I think if I can do that then the cropping problem has been defeated.

2 Answers 2


The following has worked in my case. I found the information in the official FontForge documentation published by its creator George Williams here, in the section entitled "OS/2 Metrics".

What worked was to go to Elements | Font Info... | OS/2 | Metrics and add 100 on to the Win Descent number.

For some reason neither before I did this nor after did the Win Ascent and Win Descent figures sum to 2048. They summed to 2149 before and 2249 after. I have absolutely no idea what Windows was playing at, why FontForge kept reverting the other figures, or what relevance OS/2 has to any software that is installed on my computer. If someone reading this does know, please edit this answer to make it more explanatory and therefore potentially more useful to others who may experience this problem in an environment that may be slightly different from mine. I am posting this as an answer because it took me several hours' work to arrive at it and for the time being it has solved the problem.

  • "For historical reasons, there are no less than three sets of values that deal with your vertical metrics" from this article for the macOS only Glyphs application, not FontForge, should answer many of your questions glyphsapp.com/learn/vertical-metrics. FontForge reverting to 1638 and 410 for ascent and descent appears to be a bug I am also looking into. Jan 26 at 11:13

From this FontForge discussion on GitHub it looks like the TrueType font format does not store the Ascent and Descent values from the Font Information General tab. As a test, if I save the font in the FontForge .sfd format then reopen the font, the values are retained but if I export the font as TrueType and reopen that, the values reset to 1638 and 410 which appear to be defaults.

I've read previously that the Ascent and Descent values in the General menu are misleading, they appear to affect only how glyphs are displayed within FontForge and the values that determine the final font metrics are in the OS/2 > Metrics panel (see my comment to your answer for a link to an in depth article).

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.