July 15, 2009 - Boston
With 1994’s foundation of the World wide Web and the release of the first graphical web browsers, and until 2006, unique typographic identities on the web could only be attained by converting, or rendering, outline font data into graphics, and posting the graphic. Browser developers set the default fonts of their products to fonts found on the OS each browser was made for, and this combination of pre-rendered and OS-rendered default fonts was how web typography was done. The OS, though they can handle all the fonts required for any design purpose, have been counting on the descendants of a 1989 font format to handle the web’s intellectual property and educational issues. Web designers as pointed out above, have made do with the small corral of ‘web-safe’ fonts and rendering of fonts in graphic form. The W3C tried to solve the issue by naming many formats for web font linking (2006, @font-face), but defined no methods satisfactory to the above parties, OS developers, Web designers, or browser developers, for achieving more diverse un-pre-rendered type on the web.
There have been many proposals over the years to solve this problem, but none included education for the vast new community of users implied, and none of the current proposals calls for an extension to the core format nearly all other formats come from, the OpenType format. So what would a PERM table mean to the parties mentioned above — to web users, web developers, Operating System Vendors, Browser developers, and the W3C?
Today, very few Web Users (people using browsers to surf the web) are aware of, or care about, this ‘web fonts’ issue. So seeking a solution to what users will want requires projecting into the future. Future web users will not want their browsers clogging the workings of their Operating Systems with fonts, nor the browsers presenting the users with web content that the user cannot read. In addition, web users do not want imprecisely or un-aesthetically presented content where a simple type-bearing graphic would suffice. Lastly, users do not want fonts to be able to give fraudulent users the unique corporate appearance of a genuine company.
So far, the browsers allowing use of the @font-face font linking are installing and removing fonts in an invisible way, but future browsers may need to more intelligently manage web fonts for users as more sites employ them. Here, the proposed table can help by containing the links from which the fonts came, and determining their cacheability based on the user’s browsing history. More importantly, the recommendations section of the proposed table could allow a browser to offer reconcilability of any font treatment in conflict with a user’s ‘preferenced’ desires in areas such as sizing of type, presentation of line length, and potentially dangerous type treatments such as rapid text blinking.
Today, not surprisingly, an increasing number of Web Developers are unaware of the detailed recommended uses of the digital outline fonts in the world. Outside of developing pre-rendered graphics containing type, they are ‘sheltered’ from the complexities of having to specify beyond the near bullet-proof default fonts made so far and made available for use on the web. Verdana, for example, can be scaled, letter-spaced, set on a curved baseline, and even blink with aplomb. That there are whole classes of type designs not so well suited for all these purposes, and some classes of type designs not suited for any of them, should not surprise anyone. And anyone who’s followed the rise of desktop computing, and its second act to desktop publishing, has already seen the effects of so many choices with so little education in the font. With the addition of dynamic visual capabilities, the web could certainly prove more trying for users’ eyes unless something fundamental changes the course of things.
So the proposed table contains one entire section, more than half of its contents, for recommendations and linking to more educational materials, all information targeted at web developers. Here in the table, a browser can use machine-readable data to present a human-readable representation of a server-located font library’s table contents, so the web developer may specify and visualize types in use according to, and against, the recommendations in the table. In addition or in series, the web browser can also present the permissions to the web developer enabling the developer to choose a strategy for asset use according to a site’s needs. Web developers who need to employ fully licensed fonts, or just any old font assets, can at least see what permissions a font file contains.
Today’s W3C-compliant Browser Developers fall into two broad categories: those who also bundle operating systems along with their browsers, and those who do not, supplying just a browser. The OS-bundling browser developer’s opportunities resulting from the adoption and use of this table will be discussed in the next section. Mozilla, Opera, Firefox, and the other OS-independent browser developers have had the same journey as the original browser developers, and one different from Safari and Explorer. The former have all been barely part of the loop on typography, only handing a set of user selections and web page descriptions to the OS for display. Now these browser makers must start managing fonts for users, with the OS, perhaps according to font owners’ permissions, in the path of the W3C’s typographic function creep to the future, for a clamoring multitude of web developers.
What OS-independent browser developers can do for web users was partially discussed above, but providing choices in preferences to better manage size and blinking, for example, is only the beginning for browsers. With fonts “all over the place” in performance, quality, and functionality, and nothing stopping browsers from finding and presenting linkable fonts to users, browsers could help greatly via the recommendations of the permissions table, and other data already present in fonts, to find best fits for a given user’s or web developer’s typographic needs. Of course, there are many who want these developers to ‘control’ the use of fonts through the permissions in this table, but that for future decision-making. The rich new source of data about a font’s permissions and recommendations, once available, will be of unlimited use to browser developers; and to those just developing browsers, it will pose more options for customization to users.
With only a few Operating System Developers, the benefits gained from the Permissions Table is diverse. Apple and Microsoft are both browser developers in addition to owning substantial font IP and are occasional vendors of type software. They also have deep and abiding interests in their own scaling and rendering techniques, which are driven by the format (.otf) that will contain this table. Apple and Microsoft also develop non-compliant web browsers along with Adobe who also has a huge investment in font IP and some of the most popular pre-rendering tools for web graphics.
These three companies, the inventors and developers of the OpenType specification, perhaps have the greatest long term gain from broad acceptance of this table. The operating systems developers do the most, and have done the most, outside of the type foundries, to educate users about fonts. Beside being central to the development of the OpenType format, a format that has otherwise provided for all the needs of web so far, not being able to assure web developers font volume is a minor issue. This table provides for that lack and the OS developers, in addition, will benefit from the permissions table in defining much more clearly how the font IP they bundle can be used.
The W3C today is a representative of all the interested parties named above. Their primary lone benefit from this table would be that the opportunity they created in 2006, with the W3C recommendation to use @font-face and one of several possible formats, can proceed as visualized, with additional educational data and links included, with this table in place. Any of the formats willing to carry the machine-readable table proposed here through possible conversion, glyph sub-setting, and compression, and optionally provide beneficial human-readable advice and consent on the use of the fonts.
The primary future involvement the W3C may have on this table as it progresses towards and beyond deployment, would be to assist its custodians in keeping it up to date with additional recommendations and permissions as the web continues to develop its typographic, text, and linking capabilities.
What follows then is a proposal for an OpenType Permissions table in human-readable alpha form. This is intended as a starting point for permissions and recommendations and will have all the proper technical details of storage types, communication of vital bits and bytes, and proper internationalization as it moves along.
Your comments may be highly valued on this, so feel free to send them to me, or share amongst yourselves.