On 2015-11-30 11:28, René J.V. Bertin wrote: > On Monday November 30 2015 09:58:01 Andrea D'Amore wrote: > > For the record, I understand /Library/Fonts to be the system-wide location in > which users with the appropriate status are allowed to (un)install fonts. The > font directory they *own* is ~/Library/Fonts . > Doesn't FontBook ask for an admin password when you install a font > system-wide, i.e. in /Library/Fonts, on a system where permissions on that > location are "stock"?
Probably it asks for a password, but that would not stop an administrator from adding files system-wide, as that is the purpose of this location. >> Think for example of a port that is just a collection of fonts without >> a standalone application, how would you install that and then tell >> your regular Cocoa apps about the fonts? > > There's no need to do that; the system does. In my experience (which stops at > 10.9), copying a supported font into one of the font directories makes it > available instantaneously to newly started applications (and IIRC even to > currently running applications). Be aware there might be a difference whether you create a file with low-level system calls (for example cp in Terminal) or with Finder. Only the latter automatically triggers Launch Services to recognize new items. > I don't know of any rules of precedence other than an assumed "fonts in > ~/Library/Fonts are preferred over those in /Library/Fonts are preferred over > those in /System/Library/Fonts". Other than that, my experience is that > FontBook will signal duplicates, and you end up using one of the copies > without much say over which. > The same applies to app bundles: there is very little you can do to ensure > LaunchServices will use an app bundle from MacPorts instead of another one > available elsewhere. You are right, the same applies to application bundles. I was just thinking what happens if a user already has the font installed manually. Maybe the port could even print a warning on activate? > The reasons I've been considering fonts ports : > - doxygen uses a css style that calls for Google's Roboto font. Not > necessarily as a "hard" dependency, though documentation created in Qt's help > format *will* use the font if available. > - I'm working on ports for KF5, and one of them ("frameworkintegration") > specifically mentions that the Noto and Oxygen Mono fonts are expected to be > installed. > > It would be nice to be able to install those fonts via MacPorts if the > dependents are obtained that way too. Maybe they could be placed in the app bundle, but that would cause duplication across multiple ports... > In both cases it'd require a *lot* of hacking to get those fonts to be found > in a location that's not supported by the OS, hacking of a kind even I don't > feel comfortable proposing as a port patch. It makes sense, but needs more work and a new base release. Could you file a ticket in Trac for this? > As to licensing issues ... the same principles apply that apply to other > kinds of ports. Everyone can make a port that redistributes code that isn't > supposed to be; it's up to MacPorts to prevent such ports from being included > in the official repository. The fonts I mention can be redistributed, and > ports could probably be written such that the font files are downloaded from > the official repository rather than from a MacPorts mirror. Of course I was talking about inclusion in the main ports tree and mirroring. Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev