raimue at macports.org
Mon Nov 30 03:21:33 PST 2015
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
>> 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
More information about the macports-dev