[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux



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 <funnyman3595@xxxxxxxxx> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>