Urs Liska <u...@openlilylib.org> writes: > Am 11.07.2014 09:29, schrieb David Kastrup: >> Urs Liska <u...@openlilylib.org> writes: >> >>> Am 11.07.2014 09:20, schrieb David Kastrup: >>>> Urs Liska <u...@openlilylib.org> writes: >>>> >>>>> Am 11.07.2014 09:10, schrieb David Kastrup: >>>>>> Urs Liska <u...@openlilylib.org> writes: >>>>>> >>>>>>> I think the "cleanest" way with the least hassles (and maybe >>>>>>> discussion) would be to integrate into LilyPond the _possibility_ to >>>>>>> switch fonts (e.g. Abraham's functions) and provide the fonts >>>>>>> independently. >>>>>> >>>>>> I think the salient point is to provide the infrastructure where you can >>>>>> install a font by dropping a number of files in directories, and then >>>>>> have a standard way of accessing them. >>>>>> >>>>>> The "drop a number of files in directories" part can ultimately be done >>>>>> by using GUILEv2 functionality for downloading content via HTTP. As >>>>>> long as that is not in place, just unarchiving a font tar or zip file in >>>>>> the right place would work, possibly helped with some scripts based on >>>>>> wget or similar. >>>>>> >>>>> >>>>> I'm not really sure what you mean. >>>>> Does that mean you suggest incorporating that in the LilyPond installer? >>>> >>>> No. >>> >>> I would have wondered... >>> But what are you implying then? >> >> I am not implying anything beyond what I wrote. If you don't understand >> some particular sentence I wrote, please point out what problem you have >> interpreting it. I don't see a point in rewriting my entire posting in >> different ways until the problem magically goes away. >> > > You make clear what would be necessary to provide a convenient way to > get and install additional fonts to be used by LilyPond (provided > Abraham's function has been integrated to LilyPond).
Not at all. A "convenient way" is a matter of user interface, but the underlying mechanism can be arbitrarily complex. But I was not talking about user interfaces. I _was_ rather talking about the design of the underlying mechanism which should be so simple that putting a user interface on it (even if that means leaving this to installing packages for a distribution) is not requiring anything beyond creating said user interface and/or packaging. > What I don't get is what your opinion is about to what extent this > should actually be integrated into LilyPond's downloads/installation > routines. I did not express such an opinion. Once font installation consists only of dropping files in a directory hierarchy, it is pretty much arbitrary how one does it. I pointed out that GUILEv2 would make it reasonably easy to make some sort of automated process for it, to the degree where fonts (or other resources) can conceivably be fetched and installed on-demand during a LilyPond run. But that does not mean that such an interface is necessary. The salient point is to create a situation where one can just drop fonts as files into LilyPond's file hierarchy (the installed one and/or a user-specific one) and have them accessible. The mechanism with which those files are dropped can be later improved or augmented from the basic "unpack an archive manually". -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
