On Mon, 2012-05-28 at 17:08 +0100, Weeble wrote:
> 1. I could reproduce the behaviour you saw on Windows but not a Ubuntu
> VM (but it is old, certainly not 12.04).
I worked out that it is only one version of the font that is causing the
problem. So, if you want to test it on Ubuntu without updating, use this
font directly:
http://ftp.gnu.org/gnu/freefont/freefont-ttf-20100919.tar.gz
For some reason, the bug only happens with that specific font. It's fine
with any of the older versions on that page, or with any of the .otf
versions.
> 3. I note that the Font object has a metrics() method that returns
> metrics for a glyph, as explained in this diagram:
> http://www.libsdl.org/projects/SDL_ttf/docs/SDL_ttf.html#SEC38
OK, I just tried to make sense of the metrics thing, and now I'm only
more confused than before... :S
The advance thing in the metrics for "Ubuntu Mono" is 8 for all
characters, and all characters rendered in this font return a width of
8, that makes sense so far...
Now, trying to do the same in the problematic "FreeMono" is peculiar.
It seems the advance is inconsistent between different characters, but
we already expected that. But, it's also inconsistent with the returned
widths.
As can be seen from this code, the advance says that 'a' and 'd' have
the same minx and maxx but different advance sizes, but it also shows
that the rendered size is different. Both characters render with a width
of 10, but the advance shows that 'd' should be 9.
print m.metrics("a")
print m.metrics("d")
print m.render("a", False, (0,0,0)).get_size()[0]
print m.render("d", False, (0,0,0)).get_size()[0]
[(1, 10, 0, 7, 10)]
[(1, 10, 0, 10, 9)]
10
10
Attachment:
signature.asc
Description: This is a digitally signed message part