Hi Deri, At 2022-07-16T16:21:15+0100, Deri wrote: > On Saturday, 16 July 2022 12:48:50 BST G. Branden Robinson wrote: > > [1] I think this is because it began life as, or Deri had hopes for it > > to be, an installable tool. Failing to add gropdf support for some > > crazy font that will be used only by the document you're about to > > write isn't necessarily a fatal problem, and since the whole > > "download" file gets regenerated in one pass you don't necessarily > > want to halt in the middle of writing it or you very well _may_ > > break rendering of known good documents. > > I don't understand this. BuildFoundries is not used to import "crazy > fonts" into devpdf, surely that is achieved with install-fonts.sh.
Well, since we don't install BuildFoundries and don't even have install-font.sh in our source tree, a user could argue that we leave them to their own devices when it comes to font installation. > The only purpose of BuildFoundries is to populate devpdf with the 35 > fonts which are available to devps. The only reason I consider it can > be an installable tool is because that is how I use it sometimes. Okay. But you're a very knowledgeable groff and gropdf user. > If my system installs a new version of ghostscript, or the URW package > is updated with different font names, then the entries in the download > file are incorrect and groff stops working, but running BuildFoundries > fixes it. > > BuildFoundries itself is careful not to touch other entries in the > download file, which may have been added manually or with > install-fonts.sh. Which is why it is safe to use after initial > installation of the groff package. Also, as a standalone tool we could > ask ghostscript and urw-fonts packagers to include it in the > post-installation script if the program exists on the system. I agree that this is a desirable future direction for BuildFoundries to take. Regards, Branden
signature.asc
Description: PGP signature
