Thread: [PyOpenGL-Users] any font fns on the horizon? (in Linux)
Brought to you by:
mcfletch
From: Maciej K. <ma...@cs...> - 2003-09-20 19:41:08
|
Is there any work being done on getting some font functionality into PyOpenGL? I'm mostly interested in fonts for just plain OpenGL (i.e., not GLUT, not GLContext... don't want to port my code, if I can help it). If so, what type will they be? Lines? Polygonal? Texture-based? For the time being, until something official (and solid) comes out in PyOpenGL, I've hacked myself a SWIG wrapper for a set of C functions that do texture fonts, the ones described here: http://www.opengl.org/developers/code/mjktips/TexFont/TexFont.html If anyone is interested, I can make it available. Drop me a line and I'll try to clean it up before putting it up online. Be warned though, it is just a quick SWIG wrap (and I just "learned" SWIG), *and* even the original is not the cleanest, most robust C code either. A bit of tweaking will likely be necessary. -- "Everything should be made as simple as possible, but no simpler." -- Albert Einstein |
From: <mi...@na...> - 2003-09-21 01:08:00
|
I wrote a relatively simple but effective "GLText" module for pybzengine. It's texture based, generally produces nicely hinted output, and has some Unicode support. No documentation, but there is LGPL'ed source at http://navi.picogui.org/svn/misc/trunk/pybzengine/BZEngine/UI/GLText.py --Micah On Sat, Sep 20, 2003 at 03:41:08PM -0400, Maciej Kalisiak wrote: > Is there any work being done on getting some font functionality into > PyOpenGL? I'm mostly interested in fonts for just plain OpenGL (i.e., > not GLUT, not GLContext... don't want to port my code, if I can help > it). If so, what type will they be? Lines? Polygonal? Texture-based? > > For the time being, until something official (and solid) comes out in > PyOpenGL, I've hacked myself a SWIG wrapper for a set of C functions > that do texture fonts, the ones described here: > http://www.opengl.org/developers/code/mjktips/TexFont/TexFont.html > > If anyone is interested, I can make it available. Drop me a line and > I'll try to clean it up before putting it up online. Be warned though, > it is just a quick SWIG wrap (and I just "learned" SWIG), *and* even the > original is not the cleanest, most robust C code either. A bit of > tweaking will likely be necessary. > > -- > "Everything should be made as simple as possible, but no simpler." > -- Albert Einstein > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Maciej K. <ma...@dg...> - 2003-09-21 04:06:57
|
On Sat, Sep 20, 2003 at 09:08:18PM -0400, mi...@na... wrote: > I wrote a relatively simple but effective "GLText" module for pybzengine. > It's texture based, generally produces nicely hinted output, and has some > Unicode support. > > No documentation, but there is LGPL'ed source at > http://navi.picogui.org/svn/misc/trunk/pybzengine/BZEngine/UI/GLText.py Wow, very nice! I just took it for a spin. A bit of tweaking to disentangle it from rest of BZEngine, but works like a charm now. I like that this approach uses multiple textures per font; texfont was limited to a single texture per font. I would encourage you strongly to refactor this a bit, to make it a separate, stand-alone package, since it seems terribly useful and quite robust. It seems like little work. Not only separate it from BZEngine, but hopefully from pygame as well, to give it the largest application area. I think pygame could be used to generate the fonts as a standalone utility, just like in genfont in "texfonts", which could then be pickled for use in apps which don't want to import pygame (e.g., in my stuff I'm trying to limit the number of packages it relies on...). I'm not super familiar with fonts. Could you elaborate a tiny bit on some of the terms you use in the head comment in GLText.py? I'm wondering about the full meaning of "proper hinting" and "escapement". I'm not too familiar with fonts in pygame, but my understanding is that it only handles truetype fonts at the moment. Do you know if adding support for general X11 fonts is in the plans, or even how hard a task that is? (Murphy's Law says that soon enough I'll find that I must have a given font, and it won't be .ttf... :) -- "If you sit down at a poker game and don't see a sucker, get up. You're the sucker." |
From: <mi...@na...> - 2003-09-21 07:09:54
|
On Sun, Sep 21, 2003 at 12:06:54AM -0400, Maciej Kalisiak wrote: > On Sat, Sep 20, 2003 at 09:08:18PM -0400, mi...@na... wrote: > > I wrote a relatively simple but effective "GLText" module for pybzengine. > > It's texture based, generally produces nicely hinted output, and has some > > Unicode support. > > > > No documentation, but there is LGPL'ed source at > > http://navi.picogui.org/svn/misc/trunk/pybzengine/BZEngine/UI/GLText.py > > Wow, very nice! I just took it for a spin. A bit of tweaking to disentangle > it from rest of BZEngine, but works like a charm now. I like that this > approach uses multiple textures per font; texfont was limited to a > single texture per font. Spiffy. > > I would encourage you strongly to refactor this a bit, to make it a > separate, stand-alone package, since it seems terribly useful and quite > robust. It seems like little work. Not only separate it from BZEngine, > but hopefully from pygame as well, to give it the largest application Patches welcome :) I'll probably get to this eventually, but currently I'm still at the stage of separating pybzengine from pybzflag so I can use it in another project easily. > area. I think pygame could be used to generate the fonts as a > standalone utility, just like in genfont in "texfonts", which could then > be pickled for use in apps which don't want to import pygame (e.g., in > my stuff I'm trying to limit the number of packages it relies on...). That would be a nice feature. With pybzengine this might already be possible, since it's Texture class is pickle-friendly. Would take some more work to make this work if GLText was standalone. For my own purposes I'd rather just keep this as-is, since the relevant parts of pybzengine are small and fairly general-purpose. > > I'm not super familiar with fonts. Could you elaborate a tiny bit on > some of the terms you use in the head comment in GLText.py? I'm > wondering about the full meaning of "proper hinting" and "escapement". Hinting is the process of tweaking a font's rendering a bit so stems of letters, for example, line up better on a pixel grid. Without hinting, fonts generally look a bit blurry and are hard to read at normal-looking sizes. GLText can keep fonts rendered at multiple sizes so commonly used sizes can be rendered with a one to one correspondance between pixels and texels. These common sizes can therefore be rendered with correct hinting rather than looking a little blurry due to relying on OpenGL's trilinear filtering. In the applications I've used this technique for, it has worked nicely. Small fonts are used at the same size they were rendered at, giving high quality output. Large fonts are scaled using trilinear filtering, but lack of hinting isn't noticeable. > > I'm not too familiar with fonts in pygame, but my understanding is that > it only handles truetype fonts at the moment. Do you know if adding > support for general X11 fonts is in the plans, or even how hard a task > that is? (Murphy's Law says that soon enough I'll find that I must have > a given font, and it won't be .ttf... :) Well, GLText uses pygame's font capabilities, which is just a python binding for SDL_ttf. SDL_ttf is a simple wrapper for freetype, so it will handle any font format freetype can. This includes truetype, Postscript Type1, .pcf, windows fonts, and probably more. The downside of using SDL_ttf is that it hides most of the glyph metrics stored in the original font. The glyphs GLText stores will be padded to the font's line height rather than stored in tightly fitting bounding boxes. This wastes a little VRAM, but prevents requiring real freetype bindings. --Micah > > -- > "If you sit down at a poker game and don't see a sucker, get up. You're > the sucker." > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Maciej K. <ma...@dg...> - 2003-09-21 17:43:52
|
On Sun, Sep 21, 2003 at 03:09:46AM -0400, mi...@na... wrote: > On Sun, Sep 21, 2003 at 12:06:54AM -0400, Maciej Kalisiak wrote: > > I would encourage you strongly to refactor this a bit, to make it a > > separate, stand-alone package, since it seems terribly useful and quite > > robust. It seems like little work. Not only separate it from BZEngine, > > but hopefully from pygame as well, to give it the largest application > > Patches welcome :) Heh. I won't have the time to do a complete, nicely polished package, but perhaps the stuff I do for my own project might be of use to whoever decides to go all the way. Is GLText.py code fairly stable now, or does it still change quite a bit. > Hinting is the process of tweaking a font's rendering a bit so stems of Ah, thanks. What is "escapement" then? Is it just the width of a glyph? > > I'm not too familiar with fonts in pygame, but my understanding is that > > it only handles truetype fonts at the moment. Do you know if adding > > support for general X11 fonts is in the plans, or even how hard a task > > that is? (Murphy's Law says that soon enough I'll find that I must have > > a given font, and it won't be .ttf... :) > > Well, GLText uses pygame's font capabilities, which is just a python binding > for SDL_ttf. SDL_ttf is a simple wrapper for freetype, so it will handle any > font format freetype can. This includes truetype, Postscript Type1, .pcf, > windows fonts, and probably more. Oh. So I just have to pass it the full path to a .pcf file? Just tried it; cool! Although when I tried it with helvetica, it seems it lacks metrics on ascenders because all the letters don't line up on the baseline, but are flushed to the top of the bounding box. Does this sounds like a GLText.py bug or something upstream in SDL_ttf? > The downside of using SDL_ttf is that it hides most of the glyph metrics stored > in the original font. The glyphs GLText stores will be padded to the font's > line height rather than stored in tightly fitting bounding boxes. Hmm, basically sounds like helvetica is NOT padded. I also tried "modd" font (character cell), and those were lined up. I guess the problem is only with proportional fonts (Utopia had the problem as well). I suppose it's not a big deal though.. these bitmapped fonts don't look nearly as nice as the scalable ones. -- "In a time of universal deceit, telling the truth is a revolutionary act." -- George Orwell |
From: <mi...@na...> - 2003-09-21 19:03:12
|
On Sun, Sep 21, 2003 at 01:43:58PM -0400, Maciej Kalisiak wrote: > On Sun, Sep 21, 2003 at 03:09:46AM -0400, mi...@na... wrote: > > On Sun, Sep 21, 2003 at 12:06:54AM -0400, Maciej Kalisiak wrote: > > > I would encourage you strongly to refactor this a bit, to make it a > > > separate, stand-alone package, since it seems terribly useful and quite > > > robust. It seems like little work. Not only separate it from BZEngine, > > > but hopefully from pygame as well, to give it the largest application > > > > Patches welcome :) > > Heh. I won't have the time to do a complete, nicely polished package, > but perhaps the stuff I do for my own project might be of use to whoever > decides to go all the way. Is GLText.py code fairly stable now, or > does it still change quite a bit. It still needs better Unicode support (for example, searching for missing glyphs in other fonts) but aside from that and some polishing I think it's pretty much done. > > > Hinting is the process of tweaking a font's rendering a bit so stems of > > Ah, thanks. What is "escapement" then? Is it just the width of a > glyph? Oop, forgot that one. Escapement is a vector added to the 'pen' location when the glyph is drawn. Usually the x component is the 'width' and the y is zero. It's important to make a distinction between the escapement and the glyph width though, since there may be extra space between characters or there might be overlap. Then this leads into kerning... I'm no font guru, I've just used freetype a good bit and have read their documentation ;) > > > > I'm not too familiar with fonts in pygame, but my understanding is that > > > it only handles truetype fonts at the moment. Do you know if adding > > > support for general X11 fonts is in the plans, or even how hard a task > > > that is? (Murphy's Law says that soon enough I'll find that I must have > > > a given font, and it won't be .ttf... :) > > > > Well, GLText uses pygame's font capabilities, which is just a python binding > > for SDL_ttf. SDL_ttf is a simple wrapper for freetype, so it will handle any > > font format freetype can. This includes truetype, Postscript Type1, .pcf, > > windows fonts, and probably more. > > Oh. So I just have to pass it the full path to a .pcf file? Just tried > it; cool! Although when I tried it with helvetica, it seems it lacks > metrics on ascenders because all the letters don't line up on the > baseline, but are flushed to the top of the bounding box. Does this > sounds like a GLText.py bug or something upstream in SDL_ttf? I'd guess something in SDL_ttf. I've dealt with bitmapped fonts in .pcf files before in a freetype-based font engine I wrote a while ago. Freetype handled them fine. SDL_ttf hides all the metrics from GLText. > > > The downside of using SDL_ttf is that it hides most of the glyph metrics stored > > in the original font. The glyphs GLText stores will be padded to the font's > > line height rather than stored in tightly fitting bounding boxes. > > Hmm, basically sounds like helvetica is NOT padded. I also tried "modd" > font (character cell), and those were lined up. I guess the problem > is only with proportional fonts (Utopia had the problem as well). I > suppose it's not a big deal though.. these bitmapped fonts don't look > nearly as nice as the scalable ones. SDL_ttf probably wasn't written with bitmapped fonts in mind. When such high quality free truetype fonts exist, there's no reason to use X's fonts. Bitstream Vera looks beautiful and is OSS-friendly. Before Vera was released, I had been using some fairly nice fonts from the OpenOffice and Ghostscript projects. --Micah > > -- > "In a time of universal deceit, telling the truth is a revolutionary act." > -- George Orwell > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Mike C. F. <mcf...@ro...> - 2003-09-21 22:38:43
|
Maciej Kalisiak wrote: >Is there any work being done on getting some font functionality into >PyOpenGL? I'm mostly interested in fonts for just plain OpenGL (i.e., >not GLUT, not GLContext... don't want to port my code, if I can help >it). > Realistically, no. I'm barely managing to find time to work on PyOpenGL once every couple of months with my new job, and then only for a few hours to try and integrate patches and/or work on fixing particular errors. Keep in mind that the code inside GLContext is available to rip out and use even if you don't want to use the rest of it. I tried to keep the code that actually does the rendering separate from the OpenGLContext scenegraph code. It provides polygonal (via TTFQuery/FontTools), anti-aliased bitmap (PyGame) and aliased bitmap (wxPython) font types. It does not, however, do anything with hinting. >If so, what type will they be? Lines? Polygonal? Texture-based? > > Again, nothing is planned for the core system (by me, anyway). OpenGLContext has code samples for doing all of those IIRC. >For the time being, until something official (and solid) comes out in >PyOpenGL, I've hacked myself a SWIG wrapper for a set of C functions >that do texture fonts, the ones described here: > http://www.opengl.org/developers/code/mjktips/TexFont/TexFont.html > >If anyone is interested, I can make it available. Drop me a line and >I'll try to clean it up before putting it up online. Be warned though, >it is just a quick SWIG wrap (and I just "learned" SWIG), *and* even the >original is not the cleanest, most robust C code either. A bit of >tweaking will likely be necessary. > > If you want, put a feature request on the site for linking to this module and I'll try to get to it when I find some time. Should really have links to all of the approaches we have available I suppose. Sigh. Enjoy yourselves, Mike _______________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://members.rogers.com/mcfletch/ |