[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build system: devpdf/download regression

From: Deri
Subject: Re: build system: devpdf/download regression
Date: Sun, 26 Jun 2022 17:16:44 +0100

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
> >, 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 


> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]