ImageFont.truetype().getsize() result different for Windows vs Mac version of font

[scanny]

I'm using ImageFont.truetype().getsize() to determine the rendered size of strings in a particular font as part of the python-pptx library (I'm the primary author).

This code generates a different pixel size for a Windows .ttf file than it does for the same typeface on the Mac. This behavior does not appear to depend on the typeface. The Windows result is smaller than that for the Mac:

>>> font_file = os.path.join(thisdir, 'calibriz.ttf')  # Windows font file for Calibri Bold Italic
>>> font = ImageFont.truetype(font_file, 10)
>>> px_width, px_height = font.getsize('Foobary')
>>> print(px_width, px_height)
34, 10

>>> font_file = os.path.join(thisdir, 'Calibri Bold Italic.ttf')  # Mac font file for Calibri Bold Italic
>>> font = ImageFont.truetype(font_file, 10)
>>> px_width, px_height = font.getsize('Foobary')
>>> print(px_width, px_height)
34, 12

As you can see, the height on Windows is shorter. This causes my 'best-fit font size' algorithm to pick too large a point size.

Any clue what might be causing this? The fact that the horizontal size is identical leads me to suspect a difference in the offset calculation. It seems to have appeared with the latest release in which the offset bit was fixed in ImageFont.getsize(), but I haven't done rigorous before/after testing on that.

[scanny]

Some additional information. The difference appears to be entirely accounted for by a difference in vertical offset; 1 in the Windows case and 3 for Mac in this case. The two fonts render exactly the same in PowerPoint, so I'm wondering what could make them report different offsets in Pillow.

[hugovk]

Git bisect is a great tool for finding the specific commit where things changed: http://robots.thoughtbot.com/git-bisect

There has been recent changes in PR #784 in July and released in Pillow 2.6.0:

In PIL-1.1.7 and Pillow-2.1.0, ImageDraw#textsize() and ImageFont.textsize() return size of bounding box for text.

but after Pillow-2.2.0, these methods return size of text (without offset).

[scanny]

Looks like it wasn't introduced by the recent changes, the fact that I only observed it afterwards was a coincidence.

The two font files in question actually differ in their hhea table by an amount that would roughly account for the difference. In the Mac version, hhea.Ascender, .Descender, and .LineGap are (1950, -550, 0). In the Windows version they are (1536, -512, 452). All other metrics appear to be identical. If Ascender and Descender were used by themselves in the y-offset calculation that might account for it being about the observed size smaller in the Windows version.

Another interesting observation is that in the Arial (Regular) font files from the same Mac and Windows installations, the hhea values above are identical to each other. That font file produces a consistent y-offset on both Mac and Windows.

From what I understand, the hhea values are used by OS/X for vertical positioning, whereas values from the OS/2 table are commonly used by Windows; and both are 'supposed' to use the Typo ascent, descent, and line gap values.

I've traced through the code a bit, but I'm not sure if this is a problem in _imagingft.c:font_getsize() or in the FreeType library it uses. In my case, simply having a reliable ImageFont.line_height value would do the trick, although I suppose folks who are actually rendering the fonts need a reliable y-offset as well.

Do you have any insight into the problem I'm seeing that you could offer me?

[aclark4life]

@scanny Apparently we don't have any insight, sorry about that. Please try Stack Overflow. And please reopen if you have more to discuss.

[scanny]

No worries, thanks @aclark4life :)