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 <[EMAIL PROTECTED]> 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 <[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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>
> --
> Lenard Lindstrom
> <[EMAIL PROTECTED]>
>
>

Reply via email to