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
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
