Computers & Writing Systems

SIL HOME | SIL SOFTWARE | SUPPORT | DONATE | PRIVACY POLICY

You are here: Type Design
Short URL: https://scripts.sil.org/OFL_web_fonts_and_RFNs

Web Fonts and Reserved Font Names

Victor Gaultney & Nicolas Spalinger, 2013-05-15

Introduction

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:

• to stimulate worldwide development of collaborative font projects
• to support the font creation efforts of academic and linguistic communities
• to provide a free and open framework in which fonts may be shared and improved in partnership with others

The RFN mechanism is an integral part of this OFL model. Use of it is not required, but it provides some key benefits:

• Avoids collisions - it greatly reduces the likelihood that a Modified Version would get confused with the Original Version, whether by an end user, someone bundling the font into a separate app or collection, or an application attempting to render a document that specifies a particular font.
• Protects authors - it requires any font that bears the RFNs retain the functionality and quality of the Original Version.
• Minimizes support - it enables authors to adequately support their fonts without the burden of troubleshooting fonts bearing the same name that might have been poorly modified.
• Encourages derivatives - it encourages separately-named branches to exist and be properly identified so that new, interesting enhancements can get reviewed and eventually merged back into the main project.

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.

Optimization Processes

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:

• Improving the breadth and quality of browser support, such as conversion to EOT to support legacy versions of Internet Explorer
• Refining tables and settings to match a higher technical standard, so that the fonts are more robust
• Adjusting font parameters and metadata to match other fonts hosted by the same service
• Reducing the size of the fonts to speed up loading
• Improving screen rendering, such as manual or algorithmic hinting
• Obfuscating metadata and other font details in order to make it more difficult to convert the font into something that could be installed on the desktop

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):

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:

• Supports the same full character inventory. If a character can be properly displayed using the Original Version, then that same character, encoded correctly on a web page, will display properly.
• Provides the same smart font behavior. Any dynamic shaping behavior that works with the Original Version should work when optimized, unless the browser or environment does not support it. There does not need to be guaranteed support in the client, but there should be no forced degradation of smart font or shaping behavior, such as the removal or obfuscation of OpenType, AAT or Graphite tables.
• Presents text with no obvious degradation in visual quality. The lettershapes should be equally (or more) readable, within limits of the rendering platform.
• Preserves original author, project and license metadata. At a minimum, this should include:
  • Copyright and authorship
  • The license as stated in the Original Version, whether that is the full text of the OFL or a link to the web version
  • Any RFN declarations
  • Information already present in the font or documentation that points back to the Original Version, such as a link to the project or author website

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.

TTF/OTF

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.

WOFF

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.

WOFF2

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/EOTLite

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.

SVG

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.

SVG2/SVGOpenType

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.

Flash and Javascript

There are a number of flash-based and/or javascript-based techniques intended to deliver text rendered using custom fonts onto a web page. These might be regarded as delivery of graphics rendered using fonts rather than delivery of optimized fonts, and so would fall out of scope of the OFL. All of these are now deprecated anyway, so we feel that use of such techniques either falls out of scope or does not meet requirements for preserving FE.

Subsetting

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:

• Removing glyphs, usually by limiting the character set support to a predefined range
• Removing smart font code (OpenType, Graphite, AAT) that may be useless on a particular browser platform, or simply to reduce font size
• Modifying - or eliminating altogether - smart font code to remove support for certain features or characters

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:

Pre-subsetting

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:

• As fully separate, differently-named fonts, such as "Foo ExtLatin", "Foo ExtCyrillic", "Foo Armenian" or "Foo IPA". Such premade subsets may even be part of the Original Version package.
• As virtually separate fonts, which are specified using parameters in CSS such as "subset=latin-ext". These are also premade, but delivered as subsets of a single named font.

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.

Parameterized Subsetting

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.

Dynamic Subsetting

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:

• Web fonts are normally more complete than document-specific subsets as is common with PDFs (except in the case of Dynamic Subsetting).
• The same web font can be used by many pages, whereas embedded fonts are integrated into each individual document.
• Most web fonts are not even delivered from the same server as the HTML/CSS, and one font may be served to thousands of pages.
• Web fonts remain separate resources or files, loaded separately from the HTML pages.
• The potential ease by which the general public could download and convert some web fonts into something usable on the desktop has led companies to go to great lengths to obfuscate some web fonts.
• There is even a Firefox extension (although not updated for current versions) that will download web fonts used on a page: http://code.google.com/p/web-font-downloader/
• Unlike some PDFs, for example, the content of a web page is normally still present and readable to the user even if the font is not working.

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.

Conclusions

Web font services and developers have four options when wishing to host OFL-licensed fonts using RFNs:

• Host the Original Version without any changes at all. Some authors (including SIL) are now providing web versions of their fonts as part of their normal OFL distribution packages.
• Convince the author to re-license the font without RFNs. As mentioned earlier, this is a valid strategy, but not one we recommend.
• Modify the fonts but sign a separate agreement to allow the use of RFNs. This should be the most common default strategy.
• Optimize the fonts, but do so being very careful to change the fonts only in ways that fully preserve FE, and limit the delivery formats to only those that allow for FE (TTF, OTF, WOFF and possibly EOT). This is technically difficult, but possible. However, it may be less effort to sign RFN use agreements with authors.

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.

Glyph subsetting

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:

• Removing license description and/or RFN declarations - not allowed at all, as this goes against the terms of the OFL
• Replacing the license description with a link to the full license text - does not meet requirements for FE
• Removing font identification information - not FE as it would misrepresent the font to users, such as those using tools to inspect fonts in use (such as  https://addons.mozilla.org/en-US/firefox/addon/context-font/)
• Obfuscating metadata to hide identification information or to disable conversion for desktop use (discussed earlier)

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:

• Smart font code should not be removed if there is any chance of it being used. For example, recent versions of Firefox support Graphite technology, so stripping Graphite code from a font when delivering to Firefox would not be FE.
• Preserving FE requires preserving any metadata that points back to where the complete Original Version may be obtained.

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.

Hinting

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.

Outline optimizations

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.

Table optimizations

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.

Minor fixes

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.

---

© 2003-2023 SIL International, all rights reserved, unless otherwise noted elsewhere on this page.
Provided by SIL's Writing Systems Technology team (formerly known as NRSI). Read our Privacy Policy. Contact us here.