Hello there. GNUstep has a tool called 'font_cacher', which needs to run once in a while, and scans all fonts installed in the system, preparing a cache of their names/basic info which is needed by GNUstep to run.
We have a lot of problems with this tool, which can be summed up in the following description - - The tool calls XListFonts(), and gets all available fonts - int nnames = 10000; int available = nnames+1; int i; char **fonts; /* Get list of all fonts */ for (;;) { fonts = XListFonts(dpy, pattern, nnames, &available); if (fonts == NULL || available < nnames) break; /* There are more fonts then we expected, so just start again and request more */ XFreeFontNames(fonts); nnames = available * 2; } - The tool loops on the fonts, and for each font, it calls XFontStruct *info = XLoadQueryFont(dpy, name); extracts the information it needs from the info, does its job, then finally calls XFreeFont(dpy, info); before going on with the next font. As far as I understand, there should never be more than a single font loaded at a time. This tool has been reported to cause huge memory consumptions from the X server, often ending up in a Xserver crash, on machines with a lot of fonts (typically Debian installations). I never experienced this problem (I've few fonts installed, and I don't install free type fonts or such), but it has been reported countless times from various sources. Our traditional hack-around is to ask users to filter fonts (say, only use the iso-8859-1 - font_cacher let them use a pattern to be used in XListFonts ()) ... very unsatisfactory, and can't be automated, we'd really like to have it working properly. Recently, I got his email from one of our developers (Jeff Teunissen <[EMAIL PROTECTED]>) - "It's not a bug in Xlib, it's a problem in the X server. XFree86 will happily give you the ability to have an effectively-infinite number of fonts, and most people have more fonts installed than can be used simultaneously. The problem is an optimization -- the X server doesn't load a font until an app asks for information that can't be gotten from the XLFD list (xlsfonts doesn't crash the server). What's more, the server doesn't unload fonts after you're done with them, on the assumption that you'll need them later. font_cacher has the effect of loading all available fonts into memory, but the X server doesn't have enough memory available to actually perform this. The inevitable result is a crash." Can any of you shed any light on this problem ? Is it a known bug in XFree86 ? When is it going to be fixed ? If it's not a bug, then exactly what is the way/API for looping on all fonts in the system to get the info we need ? Reading the documention, it does indeed look we are using the correct API. I've compared xlsfonts with our font_cacher sources, the only difference being that xlsfonts does not call XLoadQueryFont() for all fonts. I've also read the xfontsel sources, which seem to only load 32768 fonts, and ignore the remaining ones (is that a known bug in xfontsel I suppose ? what about the remaining fonts ?). Thanks for any suggestion and help you might provide, it's very appreciated. _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts