Hi Ingo & Deri, At 2022-06-26T17:16:44+0100, Deri wrote: > > In general, i would recommend differentiating configuration variables > > by functionality. For example, if all you need is one font path, > > i would expect having one variable to configure it. Two variables > > would make sense to me if you have two different purposes or tasks, > > for example, on the one hand a font path that gs(1) and groff *read* > > already installed fonts from, and on the other hand a directory > > that groff *writes* its own font-related files to. > > > > But it would seem unusual to me to differentiate a configuration > > variable according to the *source* of the information. For > > example, if components of the font path can come from three sources, > > 1. a static list of directories that you collect over the years > > by talking to people using different operating systems; > > 2. autoconfiguration results, for example from `gs -h`; and > > 3. user configuration, for example from a ./configure option > > then i would still expect one single variable since the whole > > point of autoconfiguration is overriding or supplementing static > > defaults and the whole point of user configuration id overriding or > > supplementing both. > > > > What would be the point of splitting the variable according > > to the source of information? (There may well be a point > > that i'm still missing.) > > I was considering priority, I wanted to ensure Users choice came > first. However, this can be achieved in one variable so long as users > choice is first, followed by the static paths, so I agree it makes > sense as one variable.
Where do we stand on this right now? Is this something I can help move along? It occurs to me that could have a single text file in the source tree which stores, one per line, a list of directories known to be useful historically for locating PostScript fonts (Ingo's #1 above). BuildFoundries and groff.m4 could each read that, turn it into a $SEP-arated search path, and prefix it successively with directories scraped out of `gs -h` output and the user's choice of `--with-urw-fonts-dir`, if any. Too bad it would be a pain to drop duplicates from the search path without disordering it. My apologies for being a bit confused and uncertain; this aspect of groff is in flux right now but I think we're making it better. Regards, Branden
signature.asc
Description: PGP signature
