Jim Wilson writes: > >David Megginson <[EMAIL PROTECTED]> said: > >> The problem is in PUI and/or the prop picker -- the font we're >> currently using does not seem to have a '|' character in it, and that >> must be throwing something off. Here's what gdb says: >> >> 0x082bceab in puFont::getStringWidth(char const*) const >(this=0x72747434, >> str=0xbffff4a0 "classes = >'terrain|astro|flight|input|gl|view|cockpit|general|math|event| >aircraft|autopilot|io|clipper|network' >(string)") at puFont.cxx:64 >> 64 if ( glut_font_handle != (GlutFont) 0 ) >> > >That would be a plib problem.
Actually I would call this a FGFS problem in that FGFS is asking for a character that is not present in the PLib font that is being used. The PLib Font system does not claim to be a universal font renderer in fact just the oposite in that it gives you only the characters that it can pack into a 256x256 image. This is primarily for performance reasons. Note that it is REAL easy to build a custom Font with whatever characters you want < as long as it all fits in a 256x256 image > > For now I'm going to replace "|" with a space. This is the practical approach but note that the '|' character may not be present in all of the 'stock' plib fonts so we may still have this problem if a user 'replaces' the default font file. FWIW I have been experimenting with using the freetype library with PLib and this would give us all the characters in any or the truetype fonts. These do look MUCH better in that they are 'true vector' fonts but they are noticeably slower to render Norman Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
