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
<mailto: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
<mailto: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 <mailto:funnyman3595@xxxxxxxxx>>
wrote:
*taps on the glass* Anybody out there?
On 8/25/08, Charlie Nolan <funnyman3595@xxxxxxxxx
<mailto: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
<mailto:funnyman3595@xxxxxxxxx>> wrote:
It was at 2.3.7. <http://2.3.7.> I downgraded
it to 2.3.5 temporarily, and it shows
the same results as 2.3.7. <http://2.3.7.>
-FM
On 8/22/08, Lenard Lindstrom <len-l@xxxxxxxxx
<mailto: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 <http://2.0.9.0>. Looks like
a match to
me.
On 8/22/08, Brian Fisher
<brian@xxxxxxxxxxxxxxxxxxx
<mailto: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
<mailto: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.