Re: RESUBMIT: afm

[Gavriel State]

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