On Apr 22, 2013, at 6:40 PM, Sam Edwards wrote:
On 04/19/2013 10:32 AM, Max TenEyck Woodbury wrote:
As I understand it, some fonts deliberately have glyphs larger than their metrics bounding boxes. Clipping them is almost certainly not a good idea.
Forgive my disbelief, but can you provide an example? It seems like Windows has the same clipping behavior (see my test http://source.winehq.org/patches/data/95792).
From my understanding, the intent of the ascent metric is that it indicates the maximum ascender on any glyph in the font (and likewise for descent), so the only real reason for the ascent/descent metrics to be wrong is if the font designer made a mistake. (And some tools, like FontForge, will automatically set the ascent/descent metrics correctly for you on export.)
I can't think of any reason why a font author would want to create a font with an invalid ascent/descent metric.
I can't speak to how Windows would render it, but one such font is Zapfino. It's an "exuberant" calligraphic font with lots of flourishes, some of which have strokes extending into the line above or below. http://en.wikipedia.org/wiki/Zapfino https://www.google.com/images?q=zapfino
-Ken
On 04/22/2013 07:08 PM, Ken Thomases wrote:
I can't speak to how Windows would render it, but one such font is Zapfino. It's an "exuberant" calligraphic font with lots of flourishes, some of which have strokes extending into the line above or below. http://en.wikipedia.org/wiki/Zapfino https://www.google.com/images?q=zapfino -Ken
I have never known about this font -- very stylistic indeed. :)
While there are plenty of strokes that go well above the cap height or below the baseline, the Win Ascent and Win Descent values (which are defined as yMax for all glyphs and -yMin for all glyphs, respectively) in the metric tables are valid - none of the glyphs violate these limits, so the patch doesn't affect this (correctly-formatted) font.
I loaded it up in Wine's Notepad, both with and without my patch, and took screenshots of the output: http://cfsworks.com/files/images/screenshots/zapfino_wine_unpatched.png http://cfsworks.com/files/images/screenshots/zapfino_wine_patched.png
I even did a pixel-by-pixel comparison: they render the same!
Sadly I can't make any comparisons to how Windows would handle the font. My Win XP VM complains about the ttf being corrupt. Is there a similar font that will work on Windows that I could try?
Thanks, Sam
On Apr 23, 2013, at 2:45 AM, Sam Edwards wrote:
On 04/22/2013 07:08 PM, Ken Thomases wrote:
I can't speak to how Windows would render it, but one such font is Zapfino. It's an "exuberant" calligraphic font with lots of flourishes, some of which have strokes extending into the line above or below. http://en.wikipedia.org/wiki/Zapfino https://www.google.com/images?q=zapfino -Ken
I have never known about this font -- very stylistic indeed. :)
While there are plenty of strokes that go well above the cap height or below the baseline, the Win Ascent and Win Descent values (which are defined as yMax for all glyphs and -yMin for all glyphs, respectively) in the metric tables are valid - none of the glyphs violate these limits, so the patch doesn't affect this (correctly-formatted) font.
I loaded it up in Wine's Notepad, both with and without my patch, and took screenshots of the output: http://cfsworks.com/files/images/screenshots/zapfino_wine_unpatched.png http://cfsworks.com/files/images/screenshots/zapfino_wine_patched.png
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
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
-
Ken Thomases -
Sam Edwards