NRSI: Computers & Writing Systems
Web Fonts and Reserved Font Names
The following paper is a draft that remains open for comment and discussion. It has been reviewed by a small group of font designers and industry representatives not affiliated with SIL, but we welcome public comment. Please send your responses to .
This paper addresses issues related to the modification of SIL Open Font License (OFL) fonts when the copyright holder has declared Reserved Font Names (RFNs - See the OFL-FAQ section 5). Any modification normally disallows the use of RFNs without a separate agreement, however some ways of preparing the font for use on the web might not be considered to create Modified Versions that would require such an explicit agreement.
The key concept in this discussion is Functional Equivalence (FE) - whether the resulting font preserves the completeness, behavior, quality and metadata of the original. There are also technical considerations related to the variety of web font formats and their ability to accurately represent the original. Our position is that use of RFNs for web fonts could be allowable within the intent of the OFL, but only in very specific technical scenarios. Above all, font authors and copyright holders (referred to simply as 'authors' throughout this paper) must not feel that the RFN mechanism that protects them and their property is being diluted or abused.
Importance of Reserved Font Names (RFNs)
The OFL is intended to be technology-neutral, future-proof, and robust. Judgments regarding OFL compliance need to always return to the foundational goals:
The RFN mechanism is an integral part of this OFL model. Use of it is not required, but it provides some key benefits:
Any mechanism that modifies fonts and expects to use RFNs must respect and acknowledge these benefits, and not dilute them. For example, a process that delivers a font alongside a web page, using an RFN, but with degraded, incomplete or incorrect glyph shapes, could increase an author's support burden and damage their reputation. This is clearly against the spirit of the RFN mechanism and would not be allowed.
There are two ways for those wishing to modify OFL fonts to avoid the RFN restriction altogether:
1) Encourage the author to release the font without RFNs. This is a perfectly valid and useful strategy, however the author would need to understand the benefits they are giving up, and the overall negative effect of allowing many different versions bearing the same name to be widely distributed. As a result, we don't generally recommend it.
2) Sign a separate agreement with the author that allows the use of RFNs. This is the preferred method. It assumes that the author has significant trust in the the expertise and intentions of the modifier. There is no prescribed format for this agreement, as legal systems vary. Authors may wish to add specific clauses to further restrict use, require author review of Modified Versions, establish user support mechanisms or provide terms for ending the agreement. Such agreements are usually not public, and apply only to the main parties. However, it would be very beneficial for web font services to clearly state when they have established such agreements, so that the public is clear that their service is operating appropriately.
For example, FFF Foundry may give ABC Corp permission to use their RFN "Foo" and distribute a Modified Version called "Foo". XYZ Ltd, however, cannot further modify that font and release it using "Foo" unless they also sign an agreement with FFF Foundry.
There has been interest by the wider OFL community in a service or web application that would make it very easy for authors to give RFN permission to specific web font services. This is a great idea, however since it would need to be separate from the OFL itself, it would be inappropriate for SIL, as primary maintainers and stewards of the OFL, to run or control such a service.
In order to provide comprehensive and robust web font services, web font engineers and developers often choose to make changes to a font before hosting it. The intent is usually a combination of:
They also prefer to host the fonts using the original names, so there is a clear correspondence between the desktop Original Versions and their optimized web versions.
These intentions are usually good, and improve the user's experience with the font. However, some of these processes remove important parts of the font - glyphs, behavior, metadata - and so the font as delivered is a Modified Version. Some processes, such as obfuscation, even intentionally remove functionality and hide metadata solely to disable the font - which goes clearly against the spirit and intent of the OFL model.
A list of the common types and methods of optimization are in Appendix A - Processes, with an analysis of whether that process produces something that could reasonably be considered Functionally Equivalent to the Original Version, and within the intent of the OFL's RFN mechanism.
Functional Equivalence (FE)
Although the OFL requires that Modified Versions must not use RFNs without separate permission, there is reasonable precedent for allowing something similar to modification - WOFF. After long discussion with many parties, that web font format was deemed to be able to produce fonts that were reasonably representative of the Original Version. There are still restrictions (OFL-FAQ 2.2):
You are allowed to create, use and distribute a WOFF version of an OFL font without changing the font name, but only if:
- the original font data remains unchanged except for WOFF compression, and
- WOFF-specific metadata is either omitted altogether or present and includes, unaltered, the contents of all equivalent metadata in the original font.
If the original font data or metadata is changed, or the WOFF-specific metadata is incomplete, the font must be considered a Modified Version, the OFL restrictions would apply and the name of the font must be changed...
These restrictions were put in place in order to preserve the identity and functionality of the font. If there is to be any allowance beyond this - even the smallest change - there needs to be some principle by which alterations are judged and evaluated, and an assessment made of whether an optimized font reasonably represents the Original Version.
The most useful principle seems to be Functional Equivalence (FE). An optimized font is deemed to be Functionally Equivalent (FE) to the Original Version if it:
If an optimized font meets these requirements, and so is considered to be FE, then it's very likely that the original author would feel that the optimized font is a good and reasonable equivalent, and that the main purposes of the RFN mechanism - avoids collisions, protects authors. minimizes support, encourages derivatives - continue to be met.
If it falls short of any of these requirements, the optimized font does not reasonably represent the Original, and so should be considered to be a Modified Version. Like other Modified Versions, it would not be allowed to use any RFNs.
Font Format Limitations
Despite very careful and well-intentioned optimization processes, some font formats have basic limitations with regard to their ability to provide FE. Does the format by its very nature make functional equivalence impossible? If so, then it will not be possible to provide that format in a way that adequately represents the Original, and so normal RFN rules with regard to Modified Versions would apply.
Here are most of the font formats that web fonts services want to provide, with comments on how possible it is to provide FE using that format.
This is typically the format of the Original Version, and can contain all the necessary glyph data, smart rendering code and metadata. FE can be preserved using this format.
This format wraps up the original font in a layer of metadata, and the result is compressed. It has already been shown that FE can be preserved using this format.
This is an emerging revision and enhancement of the WOFF format, primarily to add a better compression scheme, The project is hosted at http://code.google.com/p/font-compression-reference/ and is still in development, so a definitive judgment on FE is not possible. However, it is quite likely that FE can be preserved using this format.
EOT was one of the earliest web font formats and did not initially support all of what is needed to preserve FE. However, more recent changes in both the format and supporting development tools may provide what is needed. Deeper technical analysis of this is needed before a judgment can be made about this format.
This format is an application of the broad and powerful SVG language to draw lettershapes. It was the only format supported in early versions of the iOS platform, and so gained some popularity. However since iOS 4.2 the SVG format has not been the only option, and major web font services (TypeKit, for example) have discontinued support. SVG also has some considerable limitations in its ability to render text with reasonable quality, and supply all needed metadata. It also does not support any shaping behavior. As far as we can tell, it is not possible to preserve FE with this format, and so conversion to SVG needs to be considered a Modified Version for which RFN restrictions apply.
These enhancements to the SVG format seem to promise better potential to preserve FE, however they are still in flux and so no judgment can be made. Deeper technical analysis of this is needed before a judgment can be made about these formats.
One of the major optimization processes, supported by some web font formats, is subsetting. This can give very substantial speed optimization, and involves removing parts of a font to make it smaller and/or more efficient. Usually this also removes functionality by:
Can subsetting be used in such a way as to preserve FE? Possibly, however the technology for this is not yet mature. Subsetting is not a single technology or process. There are four major types of subsetting, only two of which might be able to preserve FE:
This technique prepares subset fonts according to preset specifications, such as Unicode range support, which are then separately made available. There are two techniques for serving these fonts:
In both cases the fonts are subset prior to being made available from a server. Because these subsets do not deliver complete functionality, and complete character set support in particular, it is not possible to preserve FE, and so pre-subsetting needs to be considered a Modified Version for which RFN restrictions apply.
This technique allows the CSS author to specify specific subset parameters to the web font service, which then assembles and delivers a customized subset on-the-fly. For example, the CSS might include an option to specify which characters are needed, as in "text=abcde". This allows for highly optimized delivery. The end result from an RFN perspective is no different than pre-subsetting, even though the delivery mechanism is different. Unless the user specifies the whole character set explicitly - which defeats the purpose of subsetting - FE is not preserved, so pre-subsetting needs to be considered a Modified Version for which RFN restrictions apply.
This technique was initially developed for CJK uses, but can be applied more broadly. A script inspects the content of the page, then requests a subset of the font containing only the glyphs required for rendering. This is currently a proprietary, patent-pending technique developed by Monotype ( http://fontsubsetter.com/ ), but similar techniques could be used by other web font services. Monotype's current demo would not qualify as preserving FE, but the technique could be extended to do so.
This could effectively provide full character set support, as any glyphs supported in the Original Version could be made available as needed. This is different from Parameterized Subsetting in that the characters would not need to be pre-specified in the CSS. If the dynamic subset were also to provide smart rendering equivalent to the Original Version, include necessary metadata, and provide access to the corresponding Original Version, then this technique might be able to preserve FE.
Dynamic Subsetting with Progressive Client Storage
This is a step further than pure Dynamic Subsetting, and involves storing the results of each individual page's font request in persistent client storage. The font is then slowly built up on the client machine, allowing for improved performance and reduced payload over time. Google has already demonstrated this technique, using the HTML5 Filesystem ( http://code.google.com/p/gwyn). As with Dynamic Subsetting alone, the specific implementation will determine whether all the requirements for FE are met, but FE may be possible with this technique.
Is It Embedding?
An alternative way of looking at web fonts sees it as only another method of 'embedding' the font in a document, like is done with PDFs. The OFL-FAQ defines embedding as "...inclusion of the font in a document or file in a way that makes extraction (and redistribution) difficult or clearly discouraged. In many cases the names of embedded fonts might also not be obvious to those reading the document, the font data format might be altered, and only a subset of the font - only the glyphs required for the text - might be included." (OFL-FAQ 1.11) When the modification of the font is clearly only part of the embedding process - such as in a PDF - RFNs are allowed.
So can web fonts be interpreted as embedding? There may even be similar technical processes as are used for PDFs - removing glyphs that are not needed, changing the font format itself, leaving out metadata.
However, there a few ways in which web font mechanisms differ from traditional embedding:
The main points here are that web fonts are not an integrated part of the document itself, and despite vendor efforts to minimise conversion of web fonts for desktop use such efforts will likely remain desirable, especially for OFL-licensed fonts. There is little reason to discourage this for OFL fonts and some authors may want to encourage it.
In conclusion, web fonts cannot be considered a simple alternative form of document embedding.
Web font services and developers have four options when wishing to host OFL-licensed fonts using RFNs:
Any other strategy that modifies fonts for web use, yet uses RFNs, violates the terms of the OFL.
Bottom line: To create a robust, comprehensive and technically optimal web font service for OFL fonts, the most practical strategy is to sign agreements with authors to allow use of RFNs. While it's technically and legally possible to avoid separate agreements with very careful engineering, the result is likely to not support all browser environments, nor give users an optimal experience.
Appendix A - Processes
The following list of web font optimization process is based on information from a variety of web font services. Each type of optimization is evaluated to determine whether that optimization could be used to preserve FE. Note that this does not give blanket approval for any particular change - it only says that that optimization could potentially be used while still preserving FE - not that use of the technique guarantees FE.
We also recommend that web font services make their optimization processes open and transparent to authors (such as in a Mercurial or Git repository) so that some optimizations can be reflected in the Original Versions rather than in separate later processes, and others tracked and reviewed.
This is covered in a separate section, above.
Conversion to other font formats
See section on formats, above.
Disabling use on desktop, or conversion for that purpose
This usually involves obfuscation or removal of metadata or name table entries, so that if the font were to be successfully converted to a desktop format it would not work properly. While this may be a valid and necessary technical response to unauthorized use of commercially licensed fonts, it is unnecessary and unhelpful for OFL-licensed fonts. User conversion and desktop use of OFL fonts is fully allowed and encouraged by the license, so to intentionally disable it goes against the spirit and purpose of the OFL. The modifications necessary also likely do not meet the basic requirements for FE - preserving metadata and functionality - so disabling conversion for desktop use needs to be considered a Modified Version for which RFN restrictions apply.
Removing or replacing metadata
Metadata is sometimes removed, abbreviated or replaced. The main argument for this is performance - to make the font as small as possible. This argument is weak, as the metadata - even the OFL itself - is not large and contributes a tiny amount to the size of a font. For OFL fonts, it is very important that all metadata remain intact and travel along with the font when distributed.
Some examples of metadata changes:
One argument for allowing metadata removal is that license and identification information can be clearly made visible in the web font delivery process. However, that only affects designers - those specifying the font - not readers who wish to identify the font in use. It also does not provide the information to secondary users, as in the case of fonts specified in WordPress templates.
Removal, abbreviation or replacement of metadata may be in violation of the terms of the OFL, and even when OFL terms are met, the font would not meet the requirements for FE, so the font would need to be considered a Modified Version for which RFN restrictions apply.
Removal of smart font routines
Smart font routines used in rendering and shaping, such as OpenType, Graphite or AAT code are often removed as they can contribute significantly to the size of the font. This is most common when the smart font code would be useless on the particular delivery platform, for example, AAT code being delivered to Internet Explorer. When this is true, removing the smart font routines does not effectively remove any functionality or reduce quality, and instead provides an improved user experience, so FE can be preserved using this process.
Two important considerations, however:
Changing font default settings
It may be useful to change a font's default settings for smart font features, or remap characters to different glyphs. In all cases those are significant changes that could not be said to represent the Original Version, would not be considered FE, and would need to be considered a Modified Version for which RFN restrictions apply.
Web font services sometimes replace the hinting present in a font for particular delivery platforms, or add hinting to an unhinted font. The intent in most cases is to improve screen rendering, so is something that some font authors may appreciate. However, hinting can significantly alter the appearance and character of a font, and what some people would consider an improvement others might consider a loss of character. Since responses to these changes are so subjective, it is impossible to guarantee that the font meets the requirements of FE. While in most cases hinting would meet the quality requirement for FE, there is no way to guarantee it, so hinting or rehinting would generally need to be considered a Modified Version for which RFN restrictions apply.
Changes to glyph outlines - and simplification in particular - can also reduce font size, especially for complex display fonts. However evaluation of these changes is quite subjective, as with hinting, and so outline changes would generally need to be considered a Modified Version for which RFN restrictions apply.
Some font development tools produce fonts containing suboptimal table sizes and formats, and internal optimization of those tables can produce faster and more robust fonts. These internal table optimizations may preserve FE, but should be tested carefully to be sure there are no unintended effects.
Other minor fixes, such as changing OS/2 table bits, Unicode range settings, tiny fixes to name table entries, setting monospace and italic bits are often improvements that make the font work better in a broader range of environments. Authors would generally consider these changes to be 'friendly' as long as they preserve FE and are truly minor fixes (not major changes). Ideally, such changes ought to be submitted to the author to be changed in the Original Version, not fixed in a later web font delivery process. However, even small, minor changes can have very significant effects which alter the font's function. These type of changes can sometimes be done while still preserving FE, but great care must be taken to ensure that FE is preserved.