-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
truetype: font metrics ascent and descent values appear incorrect #34
Comments
Your assumption that From the FreeType docs:
(https://www.freetype.org/freetype2/docs/glyphs/glyphs-3.html) |
Descent being negative might be true for the C FreeType library, but it's not true for the Go FreeType library. The Go flavor implements the golang.org/x/image/font interfaces, which allow non-FreeType implementations, and the docs for the Descent field at http://godoc.org/golang.org/x/image/font#Metrics says: // Descent is the distance from the bottom of a line to its baseline. The |
The height seems to be only slightly bigger than the Ascent. It's small enough such that characters that take up space below the baseline (e.g. 'g', 'y', 'j', 'p') gets cut off at the bottom. (For reference, see https://developer.apple.com/library/archive/documentation/TextFonts/Conceptual/CocoaTextArchitecture/Art/glyph_metrics_2x.png) This is a freetype bug: golang/freetype#34 There are multiple PRs with a fix that haven't been merged: golang/freetype#32 golang/freetype#62 Plan9port's fontsrv also similarly sums up ascent and descent to compute the height: https://github.com/9fans/plan9port/blob/047fd921744f39a82a86d9370e03f7af511e6e84/src/cmd/fontsrv/x11.c#L80
I believe this is related to #32 where eaburns pointed out a potential issue with the scale factor. I don't know a great deal about fonts, but presuming a zero line gap and that
height == ascent+descent
, I'm seeing issues withDroid Sans
andSource Code Pro
fonts usingfont.Drawer
, no hinting, 72dpi, 240pt.For example:
I'm packing glyphs in a texture and exporting the metrics for use in opengl. The above was causing my baseline calculation to be lower than expected. For now I've worked around this by scaling the ascent and descent by
size/(ascent+descent)
which produced the semi-correct result I'd expect.The text was updated successfully, but these errors were encountered: