Font size in OpenGL

[Robert Schroll]

Hello,

I just found freetype-py and started playing the OpenGL demo
(subpixel-positioning.py). It looks very useful, but when I change the
font size (on line 212), the letter spacing gets messed up.
Specifically, increasing the font size moves the letters too far apart,
and decreasing it moves them too close.

I've traced the problem to the glyph.advance set at the end of
TextureFont.load(): it seems to scale with the font size squared, which
seems wrong. (I would expect it be either linear in or independent of
the font size, depending on the units.) Is there a bug somewhere, or
have I missed another place where I have to set the font size?

Thanks,
Robert

[Nicolas Rougier]

You're right, code's wrong.
I thinkg the high resolutino advance.x calculation is wrong (in texture.font.py):

# High resolution advance.x calculation
gindex = face.get_char_index( charcode )
a = face.get_advance(gindex, FT_LOAD_RENDER | FT_LOAD_TARGET_LCD)/(64*72)
glyph.advance = a, glyph.advance[1]


Just comment these 3 lines and it should be ok (hopefully).


Nicolas

[Robert Schroll]

On 06/05/2012 02:41 AM, Nicolas Rougier wrote:
> Just comment these 3 lines and it should be ok (hopefully).

That did it. Thanks a bunch!

Robert

[Robert Schroll]

Along similar lines, there seems to be a problem with kerning. I notice
it by misspelling "The" as "Teh" in the subpixel-positioning demo.
There should be significant kerning between the 'T' and 'e', but with
Vera Sans at 9pt, there's way too much -- the 'T' and 'e' are overstruck.

In this case, the kerning distance returned in independent of font size,
so the problem decreases as the font size is increased. Playing around
a bit, I could get something that seems to be correct by adjusting line
88 of the demo to
kerning = glyph.get_kerning(prev)/64.0/72*font.size
I saw the 72 floating around elsewhere as a resolution; it seems to work
here, but I don't know if it's correct. Even if it is, the correction
should probably be moved to the part of the code that knows about the
resolution.

Thanks,
Robert

On 06/05/2012 02:41 AM, Nicolas Rougier wrote:
>
>

[Nicolas Rougier]

Right, thanks for the report. I think I've found the bug (in texture-font.py KERNING_UNFITTED/KERNING_UNSCALED) and commited the change.

Nicolas

[Robert Schroll]

On 06/14/2012 02:29 AM, Nicolas Rougier wrote:
> Right, thanks for the report. I think I've found the bug (in
> texture-font.py KERNING_UNFITTED/KERNING_UNSCALED) and commited the change.

That did it. Thanks a bunch!

BTW, I'm asking all of these questions because we're contemplating using
freetype-py (and the texture-font example) to handle text in the Visvis
plotting library. If you're interested, the discussion is here:
http://code.google.com/p/visvis/issues/detail?id=25

Thanks again,
Robert

[Nicolas Rougier]

Glad freetype-py can help you. By the way, you might be also be interested in freetype-gl (http://code.google.com/p/freetype-gl/) which is the "original" version, I just translated the subpixel-demo from it and then all the hard work is done (in fact, I checked my C code to correct the python one). Demos show different all kind of different usages.

I'm also working on glumpy (http://code.google.com/p/glumpy/) which takes a different approach from visvis (from what I've understood) for visualization using OpenGL/shader/VBO. I guess at some point it would be cool to join efforts on a single framework.

I will attend EuroScipy this summer and I think someone is presenting visvis, will be you here also ?

Nicolas

[Robert Schroll]

On 06/14/2012 12:41 PM, Nicolas Rougier wrote:
> Glad freetype-py can help you. By the way, you might be also be
> interested in freetype-gl (http://code.google.com/p/freetype-gl/) which
> is the "original" version, I just translated the subpixel-demo from it
> and then all the hard work is done (in fact, I checked my C code to
> correct the python one). Demos show different all kind of different usages.

In fact, I found that one first, and found freetype-py from there.
We're trying to keep visvis a pure-python project, so that's why I've
been working from the freetype-py examples. But next time something
goes a bit wrong, I'll check the C version and see if I can straighten
it out myself.

>
> I'm also working on glumpy (http://code.google.com/p/glumpy/) which
> takes a different approach from visvis (from what I've understood) for
> visualization using OpenGL/shader/VBO. I guess at some point it would be
> cool to join efforts on a single framework.

I had seen glumpy some time ago, but thought it only handled displaying
2D matrices as textures. Seeing the screenshots, that's obviously not
the case, so I should take another look at it.

Almar Klein is the guy responsible for most of visvis. (I just flit
around and fix things that bug me.) I've sent him an email, and you and
he can work out whether collaboration would be useful.

>
> I will attend EuroScipy this summer and I think someone is presenting
> visvis, will be you here also ?

Possibly. Almar will definitely be there, and he's the one giving the talk.

Robert