On Sunday, 26 June 2022 13:11:12 BST Ingo Schwarze wrote: > Hi Deri, > > thanks for your extensive explanation. > [...] > > In the same way that the choice of URW directory is passed into > > Foundry.in, although I would prefer separate variables, one for > > the users choice and one for the static paths. > > I didn't make make up my mind whether that is a good idea, it may > or may not be. > > 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.)
Hi Ingo, 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. [...] > Since there are quite a few aspects to consider (including > different kinds of fonts even when considering default and URW > fonts only, and the naming business), i think i will focus on > polishing the groff port for now, to help making the groff > release as good as possible, and likely return to the question > whether and how the ghostscript package can be polished once > the groff release and the update of the groff port are done. > > That seems best because i do not doubt that our ghostscript > ports in their current form provide everything groff needs, > so staying focussed is possible. > > Yours, > Ingo Cheers Deri
