Back in Febuary, Marcus Meissner wrote:
Changelog: fixed one NULL ptr problem added loading of .afm files from several common locations (ghostscript, a2ps, enscript, (teTeX), X11)
Index: afm.c
RCS file: /home/wine/wine/dlls/wineps/afm.c,v retrieving revision 1.4 diff -u -r1.4 afm.c --- afm.c 2001/01/02 20:30:16 1.4 +++ afm.c 2001/02/03 18:50:42
BOOL PSDRV_GetFontMetrics(void) { int idx = 0; char key[256]; char value[256];
- char *path;
- DIR *dir;
- /* some packages with afm files in that directory */
- PSDRV_ReadAFMDir("/usr/share/ghostscript/fonts/");
- PSDRV_ReadAFMDir("/usr/share/a2ps/afm/");
- PSDRV_ReadAFMDir("/usr/share/enscript/");
- PSDRV_ReadAFMDir("/usr/X11R6/lib/X11/fonts/Type1/");
We just did an integration with WineHQ, and this code has started to grate on me (mostly because of the fact that the AFM parser spits out a bunch of error messages while trying to parse my AFM files.
Rather than hardcoding the paths into the code, could we do this instead:
while (PROFILE_EnumWineIniString( "afmdirs", idx++, key, sizeof(key), value, sizeof(value))) PSDRV_ReadAFMDir(value);
This has the added benefit of allowing the user to specify only those AFM directories that their rasterizer knows about too. With the above, I get a whole bunch of printer fonts listed as available in wine that I can't actually print if Ghostscript isn't configured to find the font files.
-Gav