Features Download
From: Vernon Adams <vern-nztp2eEOrCR84o+VKJ9KNPXRex20P6io <at> public.gmane.org>
Subject: Re: [GFD] OFL-FAQ update draft and web fonts paper
Newsgroups: gmane.comp.freedesktop.fonts
Date: Tuesday 28th May 2013 21:16:04 UTC (over 4 years ago)
On 28 May 2013, at 02:24, Victor Gaultney

> On 27 May 2013, at 20:20, Vernon Adams
>> Is it not possible to include with a font, alongside the OFL, a
'pre-emptive permission' text that gives the user the go-ahead to use the
RFN named in OFL text when a font has been modified by subsetting,
re-hinting, etc, (i would have to think of the full list) ?? Seems a
sensible solution to me. 
> A copyright holder can certainly do something like that. The OFL doesn't
prohibit or discourage it. Such are really very separate permission
> The main caveat is that the copyright holder should be sure they are very
clear about the specific types of modifications that are allowed (and not
allowed), and how they will be judged. IOW - I think that to give others a
blanket permission to change hinting is dangerous. It would be better to
allow hinting *if the results is generally more readable than the
original*. Otherwise you could have some service that cares for only one
platform (that ignores hints anyway) completely blow away your careful
hinting and make your font look terrible on Windows.

Yes. I am suggesting that a generic text could be used that gives
permission for those specific tasks that are commonly carried out when a
font is used within a 'webfont server' service, and in a service such as
Font Squirrel. Perhaps the authors of the OFL could create such a text? A
sort of 'engineering exception' that can be voluntarilly used with the OFL?
I really don't think 'standards' need to come into it, and they are too
complicated to define.

So according to Adobe, they do the following with the OFL'd fonts they use
in their Edge service;

•	NAME table changes, including stripping of some attribution metadata
and obfuscation of Name related entries.
•	Injecting a EULA link that lives at typekit.com, which displays the
attribution metadata in an easily discoverable location. 
•	format conversions: TTF (if the original is a CFF), SVG, SWF, WOFF,
•	subset creation: we currently offer our users two subsets: "default"
(omits everything but Latin-1 plus some useful typographic marks) and "all"
(includes everything the font has to offer).
•	miscellaneous updates related to web delivery, e.g., adjustments to CFF
table's dictionary and index data in order to accommodate changes to data
location within the table resulting from subsetting; vertical metrics
adjustments for cross-browser consistency.

I would say that these type of modifications are of a different nature to
the type of modifications that i think the RFN is really aimed at. I see
the RFN as a way of way to protect the 'stylistic aspect' of a font within
the freedoms to modify and derivate.
I read the RFN part of the OFL, not as a non-permission, but more as a way
of imposing a 'common sense naming policy' when naming a derivative (and
stylistically 'different') font from an already existing font. These
engineering modifications do not effect the stylstic aspect of a font's
visual appearance.


> If you're going to give people wide and generous permissions with no
standards and no recourse, then why declare RFNs at all?
> V
> -- 
> -- 
> Google Font Directory Discussions
> http://groups.google.com/group/googlefontdirectory-discuss
> --- 
> You received this message because you are subscribed to the Google Groups
"Google Font Directory Discussions" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to
googlefontdirectory-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/E[email protected]
> For more options, visit https://groups.google.com/groups/opt_out.
CD: 3ms