On 04/23/2013 02:04 AM, Ken Thomases wrote:

Hmm. I assumed that ascent+descent+leading equals the distance between baselines. In a Mac-native text editor, the strokes of one line of Zapfino can extend into the lines above or below, which is why I figured they exceeded the ascent and descent values. Notepad doesn't let the lines get that close, though. So, something else must be going on. I guess this isn't relevant to the question at issue with your patch. Never mind. ;) -Ken

Apple and Microsoft have different definitions of "ascent" and "descent" - so you may very well be right about how Apple does it, but the OS/2 table contains "typo" ascent/descent and "win" ascent/descent... I think "typo" ascent/descent is used similar to what you described, but "win" ascent/descent (which is what is retrieved through GetTextMetrics on Windows) is for maximum/minimum glyph size. I may be wrong, so if there are any typography experts reading this, please speak up. :)

Regardless, we see this in freetype.c:
if(font->yMax) {
    TM.tmAscent = font->yMax;
    TM.tmDescent = -font->yMin;
    TM.tmInternalLeading = (TM.tmAscent + TM.tmDescent) - ft_face->size->metrics.y_ppem;
} else {
    TM.tmAscent = SCALE_Y(ascent);
    TM.tmDescent = SCALE_Y(descent);
    TM.tmInternalLeading = SCALE_Y(ascent + descent - ft_face->units_per_EM);
}

So it's clearly the intent of tmAscent and tmDescent to contain yMax and -yMin (if available) and so I feel that it's safe to clip the fonts, because it should only affect improperly-made fonts in the first place, and it's Windows's native behavior to clip accordingly.

(My head is spinning from all of this typography work ...)

And yeah, Wine's Notepad does keep the lines spaced well apart. I don't (and can't) know if that's the case on Windows or not, but it might be worth looking into later.

Thanks,
Sam