hey, just to be clear, there's been a number of people looking at your issue... it just takes a while to figure these things out. Especially when it's in our free time :)
It looks like Lenard has found another possibility. ... but back to the freetype configuration possibility. Anyone know what ./configure options gentoo uses for compiling freetype and SDL_ttf? If you know how to figure out what ./configure options your packages take, we can compare it to the configure options on win/mac. cheers, ps. Off Topic... on a non related note, I see that you can pass a transform into the freetype rendering code. So you can do rotated/scaled text. It doesn't look like SDL_ttf exposes that part of the API... but maybe that'd be a fun/useful thing to put in? On Tue, Sep 2, 2008 at 8:19 PM, Charlie Nolan <[EMAIL PROTECTED]> 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 <[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. >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
