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

-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com