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.