[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] BUG: Inconsistent font behavior between Windows and Linux
Ah, good. Couldn't bear to look at the replies until I was
half-asleep, just in case things blew up in my face. Glad to see my
various fears were unfounded. :)
James:
It was attached to the original post, looks like Brian re-attached it for you.
Brian:
Aha, test results! Much appreciated.
René:
Looks like Gentoo builds a pretty standard SDL_ttf. No patches, it
just specifies the various paths and passes on the system "Do I have
X11?" flag.
Brian (again):
I've only spotted the discrepancy at that particular size. If you,
for instance, bump the size way up to 210 (exactly 10x the original),
you get this under Gentoo:
(110, 143)
(110, 143)
<Surface(220x143x32 SW)>
<Surface(220x143x32 SW)>
[(0, 95, 0, 79, 110), (0, 95, 0, 79, 110)]
[(0, 95, 0, 79, 110), (0, 95, 0, 79, 110)]
No mismatch in the letters at all. I'd cross-check in Windows, but
VMware took offense to my most recent kernel upgrade and is out of
commission for the time being. From other tests I'd run while finding
the correct conditions to reproduce the discrepancy, I predict that if
you run it on either of your test systems, you'll get identical
results.
Looking at the behavior of the font at other sizes, it looks like
*both* of the observed results are anomalous, but that the Gentoo
flavor happens to cancel itself for display purposes. Not sure how
helpful that bit of information is, though.
-FM
On 9/2/08, Brian Fisher <brian@xxxxxxxxxxxxxxxxxxx> wrote:
> Hmm.. looks like SDL_ttf claims that it opens fonts at 72 dpi:
> http://jcatki.no-ip.org:8080/SDL_ttf/SDL_ttf_frame.html
>
> ... so how is the point size supposed to map to pixels then? Does 72 dpi
> seem to be correct?
>
> Also, if you make the font much much bigger, does the size discrepancy on
> gentoo Linux get bigger proportionally as well?
>
> On Tue, Sep 2, 2008 at 10:30 AM, Lenard Lindstrom <len-l@xxxxxxxxx> wrote:
>
>> 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>
>>
>>
>