OpenGLEAN
OpenGLEAN gleanfonts User Support
Home page | Introduction | Documentation | Files | Examples | Proposals | Authors | Links


OpenGLEAN gleanfonts development
Summary | CVS | (discussion via home page) | (contact via home page) | (suggestion box) | License | Todo | Bugs

Unified Model Space Fonts

Introduction.

This proposal seeks to explain and justify a new font API for OpenGLEAN.

Where we are now.

Old GLUT defined two font APIs, really. One was for bitmapped fonts, and the other was for stroked fonts. freeglut extended the APIs a bit to include string based functions that were both faster and more convenient. Additionally, some further font metrics were defined to allow better handling of the fonts.

Old GLUT's API under UNIX allowed you to supply your own font data, if you knew GLUT's font data structure. freeglut seems to have inherited this. Under WIN32, both old GLUT and freeglut use integer handles, which are type-cast to void * for source compatibility with UNIX.

To avoid providing clients with handles onto library data, and to make the library OS-independent, OpenGLUT made the UNIX_X11 build behave like the WIN32 build. I.e., OpenGLUT uses integers---cast to void * for historic reasons---rather than actual object references.

Why this is not sufficient.

Bitmapped fonts were unsatisfactory as they could not be readily scaled, rotated, etc. Both APIs only defined a handful of fonts.

Having to use two different APIs for something that, from a client perspective is essentially one task, is also a liability.

Some responses to this problem.

There are several ways to cope with this.

One is to simply ignore it and direct users to use other font libraries if that is their need. If taking this view, it is reasonable to propose that we should remove the old GLUT font API (and fairly hefty data) from the library. A drawback to doing all of this is that the font libraries that I have seen tend to be restrictively licensed (GPL or LGPL).

Another solution is to augment the GLUT fonts. This won't address the fact that bitmapped fonts can't be operated on by OpenGL matrix operations, unless something further is also done. And the act will also cause the library to swell up considerably with fairly "dead" data. And it is hard to draw the line; my X server has access to literally thousands of fonts, but I wouldn't dream of putting them all into OpenGLEAN.

A variation on this theme is to allow system fonts. This is arguably the most in keeping with OpenGLEAN's role as a window-system portability library. System fonts tend to be easier to access if you have a system-dependant window handle (something that OpenGLEAN keeps in itself). A huge range of fonts at varying resolutions are also available, and there is virtually no cost to the library for doing this. Proprietary fonts installed by the user also become available. The only downside is that fonts do not have terribly uniform naming conventions. E.g., on the Amiga, the fonts that shipped with the original OS were named for stones, such as "topaz" and "ruby"; even if a suitable font is available, it may be hard to find it. Selecting appropriate fonts may require user assistance, and the fonts probably will not be directly subject to OpenGL transformations.

Another response is to convert the builtin bitmapped fonts to textures. This doesn't address the relative paucity of the GLUT fonts, but does allow the stroked and bitmapped fonts to be unified so that they act the same.

A very desirable feature is to allow the client software to provide its own fonts. This does not come up often, but avoids the mild difficulties of nonstandard system font names, while giving the application author access to any font that they can get. This requires that the author provide the font data to the library, of course, and by the time that all is said and done, it is not clear that one has gained anything over just using a custom data structure and OpenGL raw operations.

A final suggestion is to support procedural fonts. E.g., client-supplied fonts could be handled by giving a callback to OpenGLEAN, and OpenGLEAN will use your callback for rendering font glyphs, trusting you to "do the right thing" with the current rendering position, etc. This affords great flexibility and fits well within the GLUT paradigm of callbacks. The biggest argument for not doing this in OpenGLEAN is that there is little relation to OpenGLEAN's primary role, other than sympathetic (most window system tools/libraries provide fonts). Lacking any other place for this propsal, however, we will keep it here.

The Proposal

The following ideas are proposed, then:

C++ programmers can think of such a font as a class, of course.

Setting up a new font would probably look like so:

  GLUTfont fid; 
  fid = glutCreateFont(
      font_render,
      font_metric,
      charset,
      first_glyph,
      last_glyph
  );

font_render and font_metric would be callbacks. charset should be a symbolic constant. (A reserved charset name of GLUT_CUSTOM_CHARSET, or similar, would be provided as a catch-all.) This is how OpenGLEAN would know whether your character set can be translated.

The first_glyph and last_glyph pair define a contiguous range of glyphs that you wish OpenGLEAN to believe your renderer and metric callbacks can handle.

If font_metric is given as NULL, then the font will be assumed to render 1x1 glyphs from left to right. (Details about font metrics are otherwise deliberately left vague for now.) The metric function would not be needed during normal rendering, as font_render is presumed to adjust positioning accordingly.

Additional information may be accepted or required, such a a string name for the font, though perhaps that could be obtained from the metric function. The intent of additional information on the font is to permit a font module to be added which can scan available system, TEX, TrueType, or other fonts and allow your client to do a heuristic match (e.g.: Font name is "courier" and size is 24).

Font size should be in real world units at which the font looks good. As GLUT uses millimeters elsewhere, those are the suggested units here. A separate metric request should indicate if the font's size is truly known or if the size merely indicates a ration of width to height. (E.g., if a NULL font_metric callback is provided, OpenGLEAN won't know anything for certain and will guess that the font glyphs are as wide as they are tall---reporting a 1x1 size.)

font_render and font_metric would be allowed to operate on strings of data (issue: char * data, or int *? Or long *? or have multiple forms?)

Issue: Allow one to specify multiple glyph ranges for a single font? (Probably not; just skip unacceptable characters in the callback itself.)



SourceForge.net Logo Supported in part by SourceForge.net.

Generated on Sun Sep 18 12:47:35 2005 for gleanfonts by doxygen 1.4.3
The OpenGLEAN Fonts project is hosted by SourceForge.