Hi Charlie,Your problem was not being ignored. But I could find any operating dependent places in pygame.font. Apparently there are though. Character size, in pixels, depends not just on pitch, but also on the screen resolution, dots per inch. This is a feature of FreeTypes, on which pygame.font is built. The screen resolution is an arbitrary value that can vary with operating system, and can be customized on Windows. I will look to see if the screen resolution can be set for FreeTypes when I get the time. Here is a link to the FreeTypes mailing list posting explaining why pixel sizes vary:
http://lists.nongnu.org/archive/html/freetype-devel/2002-08/msg00020.html Lenard Charlie Nolan wrote:
Okay, we don't quite seem to be understanding each other here, so let me be explicit. 1. This is not a large issue, and I understand that. It's a 1-pixel error, and if there are other priorities at the moment, fine, say that. At the same time, that 1-pixel error triggered word-wrapping and caused a perplexing bug on my end. Isn't this exactly the kind of cross-platform issue that python and pygame are supposed to prevent? 2. I am not a C/++ coder, nor do I know SDL. Last I checked, that was kinda the point of pygame: you don't have to. From where I sit, this looks like a bug. It's possible that it's a version mismatch or some obscure option, but I've got no way to determine that unless you tell me how. 3. As mentioned, I suspect this is an underlying SDL issue. As a result of point 2, I can't exactly go to them with this myself, because I neither know nor care about how pygame handles fonts. I just want it to work correctly. Therefore, if this is an SDL issue, I need someone to take it to them for me. 4. We could rapidly narrow down the list of possibilities if a couple people would take 5 minutes (if that) to run the test I gave and see who's affected by it. I have confirmation from my end that it's appeared on at least three separate Windows systems, so other *NIX results would be particularly useful, and not, I would think, terribly hard to come by here. 5. In the abscence of suggestions or external test results, I am left to assume that I'm being ignored and/or swept under the carpet. I've done my best to give you every piece of information I could, so I don't feel it's unreasonable to expect minimal effort on your part in return. Throw me a bone, here! -FM On 9/2/08, René Dudfield <renesd@xxxxxxxxx> wrote:hi, It's likely the different compilation options for freetype. Or even gentoo specific patches to freetype or sdl_ttf. Otherwise it could be different bitdepth surfaces. eg, 24bit on one machine and 16bit on another. cheers, On Tue, Sep 2, 2008 at 4:04 PM, Charlie Nolan <funnyman3595@xxxxxxxxx> wrote:*taps on the glass* Anybody out there? On 8/25/08, Charlie Nolan <funnyman3595@xxxxxxxxx> wrote:So, anything else you want me to poke at, or is someone going to take a look? For that matter, have you guys been able to duplicate the problem? -FM On 8/23/08, Charlie Nolan <funnyman3595@xxxxxxxxx> wrote:It was at 2.3.7. I downgraded it to 2.3.5 temporarily, and it shows the same results as 2.3.7. -FM On 8/22/08, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:That's right for SDL_ttf. What freetype version does Gentoo have. Pygame 1.8 uses freetype-2.3.5 on Windows. Lenard Charlie Nolan wrote:SDL_ttf is at 2.0.9 on Linux, and after digging a bit, the SDL_ttf.dll that came with pygame shows version 2.0.9.0. Looks like a match to me. On 8/22/08, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:It may be a difference between different versions of SDL_ttf or of freetype, which may not be a bug if the new er behavior is part of a bug fix. So what version of SDL_ttf do you have on Windows and on Linux? On Fri, Aug 22, 2008 at 12:04 PM, Charlie Nolan <funnyman3595@xxxxxxxxx>wrote:I suspect this will just get passed upstream to SDL, but someone will need to translate for them. The "7" glyph in the attached font at size 21 behaves inconsistently on Windows (XP SP2) and Linux (Gentoo). Running the test script on the two systems, I get these results: Linux: (11, 16) (12, 16) <Surface(22x16x32 SW)> <Surface(22x16x32 SW)> [(0, 9, 0, 8, 11), (0, 9, 0, 8, 11)] [(0, 9, 0, 8, 11), (-1, 9, 0, 8, 11)] Windows: (11, 16) (12, 16) <Surface(22x16x32 SW)> <Surface(23x16x32 SW)> [(0, 10, 0, 8, 11), (0, 10, 0, 8, 11)] [(0, 10, 0, 8, 11), (0, 11, 0, 8, 12)] My interpretation of this is that the 7 is behaving a bit screwy at that size. It renders as 12x16, but has an X offset of -1, for an effective size of 11x16. On Windows, the X offset appears to be lost, thus causing the glyph to incorrectly have an extra pixel of padding on the left. I'm also puzzled as to why maxx is one larger on Windows, but that part doesn't seem to cause a problem.
-- Lenard Lindstrom <len-l@xxxxxxxxx>