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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > wrote: >> *taps on the glass* Anybody out there? >> >> On 8/25/08, Charlie Nolan <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >>>>>>> <[EMAIL PROTECTED]>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. >>>>>>>> >>>>>>>> >>>>> >>>>> >>>> >>> >> >
