-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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 fonts rendered from top pixel instead of top of font #285
Comments
Can you send a PR to fix this issue please? I remember some confusion at the time about it… but I thought we had it figured out. Thanks |
IIRC, we've already applied and reversed one patch for this or very similar behavior. I think that perhaps it's time to define exactly what behavior we want from draw.text, then test the hell out of it. I'd propose that there should be a consistent distance from the starting point to the baseline of the text, based on the font/size. Specifically, I'd think that it should draw based on the Cap Height, and that ascender height should potentially be over that. (see http://en.wikipedia.org/wiki/Typeface#Font_metrics) There are some fonts where there's significant difference between the ascender height and the capital height (especially in script fonts, like Zapfino). Alternately, we could add something in that would draw fonts based on the baseline position, which would be the ideal reference for getting rid of all of this, as it's the most stable point of any. |
I was going to raise an issue on this as I am wanting to switch pi3d to Pillow and its behaviour is different (and wrong!) It's especially noticeable for us as we draw each character individually to a texture then uv map them onto 3D surfaces. There is an 'anchor=None' keyword argument to the text() method maybe this could be used to vary which font metric to use to anchor the x,y location. Default behaviour should be to draw the text base line ascent (value from hhea table in truetype font) distance below the x,y location. |
@paddywwoof Thanks for the feedback! Hopefully a "fix" (something everyone agrees is the right fix) for this will go into 2.2.0 |
@aclark4life Sounds good. Any idea when 2.2.0 is scheduled for? I've not done more than look at source on github but my vote would be for ascender = PIXEL(self->face->ascender); |
I don't know if the current master branch will just become 2.2.0 or otherwise how to get a revised version to test it out. Do I have to make my own branch then submit a pull request? If someone is already set up and working on this project then they could try it for me (and put in the pull request too). What I would try is to change |
Master is 2.2.0 |
OK, not so simple as my suggestion. Obviously more changes impact on this subsequent to efd70fb. I will carry on looking at it when I have time but for the moment I have added a hack to (our project) pi3d code to prepend a '|' onto the start of each string then not display it (yes it's horrible!). Also I noticed with this new code that supplying color for text to draw onto an rgba image seems to require an rgba tuple. This means that existing code that worked with PIL specifying text color like "#ffff00" or "cornsilk" will crash. Maybe ImageColor.py line 102+ should be
this lets me use my existing code |
I've fixed these two issues to my satisfaction: https://github.com/paddywwoof/Pillow |
Removed symlink as Pillow now checks /usr/local/lib/libfribidi.dylib
As of this commit in Pillow 2.1.0, TrueType fonts are drawn from the top pixel down, instead of from the max height of the font. This means that lines containing only half-height lowercase characters, for example, are rendered at a different height than full-height characters. Because of this, it's basically impossible to evenly space text over multiple lines.
The text was updated successfully, but these errors were encountered: