Re: [openglean-devel]Font support.
Status: Beta
Brought to you by:
rkrolib
From: Richard R. <sf...@ol...> - 2005-09-18 03:32:28
|
Sorry for the length of this. I've batted around font ideas for a while, so this is kind of a core-dump of everything that is currently in my head. On Sat, Sep 17, 2005 at 02:19:37AM -0500, Richard Rauch wrote: [...] > The upshot is that adding new fonts to the library should be > difficult, but making a good API for using the fonts properly ...err, should NOT be difficult. (^& Varol: I can't reply directly. Your initial email had the appearance of an administrative request, to SourceForge (I'm not sure why). After I approved it, it was marked with an invalid tag by SourceForge's own spam-filter, because of the way SourceForge handled the email, so it got rejected at olib.org. So I can't directly see, or reply to, it---I can only read it on the SourceForge list archive. Nor can I see the screenshot that you attached, since the archive doesn't include those. Maybe you can put it up somewhere on the web and post a URL? To answer your specific questions: 1. I think that some more embedded fonts are a plus, so that the library can guarantee certain fonts will be there, without the application having to burden itself with font files, etc. Whether the font data is physically in the main library or is in a well-known file that is shipped with the library is not so crucial. But as I think that the number of fonts that should be guaranteed makes a small set, I don't think that it hurts so much to have them in the core library. But I also think that the ability to access extended fonts is essential (more than just whatever is included with the library). More on that below. (^& 2. I want to avoid hard dependencies such as on freetype. I think that an interface to something like freetype would be nice. And to TeX fonts, etc. 3. Yes, Unicode support and right-to-left rendering are desirable. I do not know these areas well, but I want to permit it. Font support has been discussed before in other forums for extending a GLUT like library. Here are my thoughts: * A relatively small number of guaranteed fonts that are always with us is useful. The past couple of days, I implemented part of an old API proposal, cowritten with others, which called (among other things) for the 14 Adobe PDF fonts to be added in certain common sizes. I was unable to readily get three aspects covered: The fonts are all ISO-8859-1. The "ZapfDingbats" font is not available. The size 36 version of the fonts was not available in a way that I could extract with the current tool. * No pre-defined set is going to be sufficient for everyone. There needs to be a way to access both "system" fonts and application- specific fonts. I do not intend to put all of the thousands of fonts from XFree86 or X.Org into the library, much less to start harvesting other font libraries. But clients should have access to whatever fonts the user has on their system. * I think that switching to a string-based font identification scheme is best. The string should encode some basic things about the font (size/resolution if bitmapped; character set; whether bitmapped or stroked; ...). The basic things may not uniquely identify the font, but should allow one to determine some characteristics about the font. The string name would also encode a source of the font, and a unique id within that source (e.g., a "system" font on X11 could have the X11 font specification string). One virtue of the naming scheme is that it would let you search for a font such as "helvetica" and see if any font in the system had such a name. "The" Helvetica may not come in the size that you want, but there may be another Helvetica that is better suited to your needs. Perhaps more importantly, it provides a way for a user to guide a program to find fonts that may only exist on their computer, and which in any case the core library has no reason to know about. * I'm currently leaning towards the idea that a "font" would be handled as a collection of functions (or function-pointers---think callbacks for client fonts; (^&) that are tied together under some identifier. Something vaguely like this, perhaps: my_font = gleanfontCreate ("whatever my font is called"); gleanfontDrawFunc (cb_my_font_draw); gleanfontDrawStrFunc (cb_my_font_draw_str); gleanfontWidthFunc (cb_my_font_width); gleanfontWidthStrFunc (cb_my_font_width_str); /* ... */ The core library could be smart enough to say "To draw a string, if there's a string-drawing function, call it directly; if there isn't, then call the single-character function in a loop. So it would not be necessary to provide all callbacks for every font." * Extending this idea a little, a font repository could be another collection of functions that manage an interface to multiple fonts organized and accessed in a particular way. This lets us define a library with old-style fonts, then wrap a font-repository layer around it that uses the same callbacks for every font in the library. Then another (very different) wrapper could be put around freetype. And another around TeX. Etc. The wrappers themselves would have a standard interface. These "layers" can be separate shared libraries that are explicitly loaded. This way we avoid building knowledge about TrueType (for example) into the library, avoid forcing one to have (for example) freetype installed to compile/use the basic library, and still allow one to use (for exaple) freetype to access (for example) TrueType fonts. As you can see, I've thought about it a bit. I hope that some of my thinking has been productive. (^& I would welcome: Ideas, critiques of any of the above ideas, and actual code. In code, I'd like to avoid hard dependencies on external libraries such as freetype. What I've done up to this point has been an incremental extension of the basic fonts to a couple more typefaces and more sizes (and more uniformly populating the available sizes). I have not at this time put Unicode support into the library, but I suspect that if I changed the X font identifier name that I pass to specify the ISO-10646 character set for some of the fonts, we'd have unicode. I haven't done that partly because I didn't want to embed *that*much* data into the library. And, too, I think that proper Unicode support will mean modifying the core API (right-to-left, top-down support). -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |