Hewlett Packard Co., April 16th, 1996 Ben Bauermeister
As the audience on the Web grows to include more commercial activity and present information in a more visual context, the use of type as a visual element needs to be supported. While the initial response to a need for better typographic support has focused around compression, a better understanding of what the real Web needs are, where emerging technologies have stumbled in the past with regard to type, and where the work needs to be implemented for robust Web based type solutions indicates that cooperative efforts need to be established to attain the goal of easy to access and visually appealing information on the web.
Areas of Technical Development
Typographic complexity is needed on the Web if it is to thrive as a publishing format for vast and diverse forms of visual communications. Yet these needs do not focus solely around the needs of font compression - rather around the customer needs for document compatibility, flexibility and choice in font selection, protection of the designs created by today's typographers, and reducing the transmission time for loading a visually rich document.
The Web has been able to grow at incredible rates of adoption and technical improvement based on one fact: the strong trends of technical competition have been balanced with an unprecedented amount of device interoperability. This compatibility must not be compromised by type. The mechanisms that are created and implemented today to support font transmission must remain open to all comers and support the known standards of today's electronic publishing world.
HTML and its eventual font formats, either compressed or sub-setted or fully formed need to remain as non-proprietary, open standards which appear to the end-user as transparent elements of their visual communication based on the ubiquitous implementation of these technologies across all Browser platforms.
The technologies that are adopted to facilitate the transmission of font data across the Web need to be based on the same technologies that customers rely upon today. This means that the architectures that are implemented must support both TrueType and Type 1. This includes support for any character set and language.
The viewer of the document cannot be expected to understand, locate, purchase, or install the technology necessary to experience the full impact of the author's intended communication. Failing to meet these needs will result in the same customer confusion and frustration that hit the publishing community during the last font war between TrueType and Type 1 on the PC desktop. Only this time it will be at the expense of the consumer, not the author and this is a cost that no advertiser will bear.
It should be noted that at the root of this discussion is an intent to distribute the intellectual property of font designers with little or no personal gain their efforts. Again, looking at the successes and failures of font licensing in the current electronic/desktop publishing market may yield directions in a better solution for the Web.
A solution is available to Browser applications that was not easily implemented on native desktop applications. This solution involves two classes of fonts, one class for authoring and one class for presentation of information. The authoring fonts consist of those types that an individual has purchased for use with the documents that they create personally. These fonts can be used either for authoring or for presentation. The presentation fonts consist of fonts that have been transmitted to their machine in conjunction with a specific document or site. These fonts should have the full capabilities of any authoring font with regards to high quality printing and display. They should not, however, appear in any font menus nor be available as a resource to other authoring applications.
Providing a separation between authoring fonts and presentation fonts is a unique opportunity of Browser applications, giving these applications a level of functionality that has not been supported by the base operating environments to date.
In a perfect world, the end-viewer should not perceive any difference in the time it takes to receive a visually rich document that includes font and image than a block of simple text. There are three major factors in achieving that perfect world, and they are data reduction, data compression, and raw data transmission.
Most of the gains in transmission speed will be achieved by data reduction, not data compression. For those type faces that are used for subhead or emphasis styles in which nominally less than 50 characters are required proper sub-setting of the font will provide a file size reduction of 70% or more from either a Type 1 or TrueType font. Fonts that are used in simple headlines may pose only a 3-6K impact on the overall document size. Reducing the font in this way also further supports the notion of a presentation font - limiting the fonts usefulness to the current document only.
Data compression in addition to data reduction can further reduce the size of the file. Yet three important factors must be considered for the data compression. First, the gains of any compression technology lessens when the data sample is smaller. The characteristics of font file specific compressors will likely be even more limited by subsetted fonts. Our initial research shows that compressors specifically tuned to compressing TrueType files yield only 2-3 % advantage over well known data compressors like PK Zip.
Secondly, if a -general purpose compression routine is used for font compression, this technology can also be used to further compress other page elements such as image data and style sheet information.
Finally, the target hardware platform for most of this compression is to support 14.4 modem connections. Most 14.4 modems support hardware assisted data compression of all information going across the line. The resulting sizes of sub-setted and compressed font going across the wire will be little different from a font that is only sub-setted.
In order to support the request, transmission, installation, and rendering of type in a system which is somewhat distinct from the operating environment, work needs to be completed on several components. Below is a summary of these work areas with some detail to potential areas of overlap and error.
There have been several proposals for the actual tagging structure within HTML for requesting fonts. The best news on the tagging front is that no single vendor seems to be garnering support for a specific tagging structure that can be used as a divisive lever for text superiority. HP is proposing that trademark non-specific PANOSE numbering or some similar scheme be used in addition to the font name for better portability and rendering.
In addition to the name tagging it is recommended that the tag structure follow as closely as possible the type specification process used in the publishing fields. This includes actual point size specification and individual names for styled variants within a font family rather than style bits and overly generalized weight classes.
Web Font Manager is the term I use to encompass the umbrella architecture within a Browser for receiving, decompressing, and installing either TrueType or Type 1 files. This code should present an API that is compatible with the font tagging scheme as well as a mechanism to install the resulting typeface. The actual interface to the Browser code will likely need to be modified to be compatible with the various Browsers available.
In addition to supporting the new font tags that reference the desired font file, the Browser could support the notion of a presentation font versus an authoring font. In this case the font would be loaded as a resource to the Browser rather than installed as a system level resource.
For most of the recommendations presented here the operating system need not be modified or extended. This is a goodness. On the other hand, were there application level support for presentation fonts in the operating system a significant burden for font management would be removed from the Browser. Over time, as more applications in addition to Browers start to display rich content from remote sites the issue of font transmission and distribution will become an issue that may well be best handled by the operating system.
As the engineering team within the Hewlett-Packard's Business LaserJet Division probed deeper into the requirements for font transmission within the context of HTML and current Browser architectures several issues were raised that require wider consensus to resolve. These issues are presented below without any currently proposed or known solution.
As mentioned above, there is an advantage to having the fonts used in received documents as standard OS level resources. Steps that are taken in the short term to remedy the lack of support for presentation fonts in the operating system may be necessary to add the required functionality in the short term - but should not been seen as a long range strategy.
It is likely in the course of viewing several different HTML documents that the same font, used in different document locations, may need to be loaded several times onto the same machine. It is difficult to solve the problem of multiple downloaded subsetted font files of the same name. Constantly reconstituting larger font files made up of various subsetted fragments will add to performance problems and will remove any advantage won by compressing the fonts in the first place. Creative solutions are needed to surpass this problem. We have investigated ideas of random font naming, merging subsets, and serially numbering fonts based on their arrival. None of these options has provided a solution that is elegant or bullet proof.
Unless a Web Font Manager is used, Browsers will need to support a variety of font formats from independent sources. This will result in redundant code and a poor usage experience for the user. We do not think that it is in the best interest of the customers or the Browser creators to implement an open API into which you could plug any number of font technologies.
HP is dedicated to making the documents on the web accessible, open, and easily supported in hard copy. To this end, the font standards that are adopted on the web are of great interest to HP. HP is interested in offering its time and expertise where ever possible to furthering the technical development of Web centric documents. Specifically, the areas listed below are places where HP has and will continue to develop technologies for the Web
HP has under development compression routines that yield font files that when decompressed are identical to the original source files. This technology is based on the LZ1G compression routines created in Hewlett Packard's Palo Alto based research labs. This compression technology is being developed in conjunction with TrueType specific subsetting code. These technologies will be available for review in the very near future.
HP has actively been communicating with Adobe, Microsoft, NetScape and a variety of traditional font suppliers to integrate a customer focused, open method of font exchange that meets the needs described above.
While HP has several pieces of technology that can be integrated into the solutions needed for richer document exchange, we will actively support any and all font technologies that are open, non-proprietary, and freely available on the World Wide Web.