PNG: The Definitive Guide

Chapter 2. Applications: WWW Browsers and Servers

Since the Web is where some of PNG's more uncommon features--alpha, gamma and color correction, two-dimensional interlacing--are most apparent and useful, it makes sense to begin our coverage of PNG-supporting applications with a look at web browsers and web servers.

Like all of the application chapters, this one has aged a great deal since 1999--at least, the browser part of it has. (The status of web servers is virtually unchanged.) With the exception of the final rows in Tables 2-1 and 2-3--which describe the level of PNG support in Netscape Navigator and Microsoft Internet Explorer, respectively, something that continues to be of particular interest to readers of this book--I have not updated the text in any way. However, the PNG web site is updated regularly and includes both a general summary of browser status and a complete list of PNG-supporting browsers:

http://www.libpnq.orq/pub/pnq/pnqstatus.html#browsers

http://www.libpnq.org/pub/pnq/pnqapbr.html

It complements the more detailed and explanatory information presented in this chapter.

2.1. WWW Browsers

Although there are dozens of web browsers available, most of which have supported PNG since 1995 or 1996, for the vast majority of users and webmasters there are only two that count: Netscape Navigator and Microsoft Internet Explorer. Collectively referred to as “the Big Two,” these browsers' level of support for any given feature largely determines the viability of said feature. PNG support is a good example.

2.1.1. Netscape Navigator

Netscape's Navigator browser, which originally shipped standalone but more recently has been bundled as part of the Communicator suite, supplanted NCSA Mosaic late in 1994 as the standard browser by which all others were measured. Version 1.1N was released in the spring of 1995, at roughly the same time as the frozen PNG specification, but despite the hopes and efforts of the PNG developers, the first Navigator 2.0 betas shipped later that year with animated GIF support rather than PNG. Navigator 2.0 did offer the possibility of platform-specific, third-party PNG support via Netscape's new plug-in interface, but only for Windows and Macintosh. Alas, even that was fatally flawed from an image-support perspective: Navigator's native image-handling code (via the HTML IMG tag) had no provision for handing off unknown image types to plug-ins. That meant that even if PNG plug-ins were written for both supported platforms, and even if a majority of users downloaded and installed a plug-in, it would be useless for standard HTML--only pages using Netscape's proprietary EMBED tag would invoke the custom code. Moreover, Navigator 2.0 plug-ins were given no access to the existing page background, which meant that PNG transparency would be completely ignored.

The Navigator 3.0 betas in 1996 extended plug-in support to include Unix platforms as well, but they fixed none of the fundamental problems in the plug-in API.

[13] The interface was considerably revamped in 1997 for the 4.0 betas, however, finally allowing transparency support via something called a windowless plug-in--though only for the Windows and Macintosh platforms. Support was also added for images referenced via the new HTML OBJECT tag. But the basic lack of a connection between plug-ins and the native IMG-tag code persisted, and this barrier extended to the new OBJECT-handling code as well--even a JPEG or GIF image in an OBJECT tag would fail unless an appropriate plug-in were found. Should the outer OBJECT happen to be a PNG, Navigator would fail to render even the inner GIF or JPEG in the absence of a PNG plug -in. Unlike IMG tags, Navigator required OBJECT tags to include the otherwise optional HEIGHT and WIDTH attributes to invoke a plug-in. In at least one version, the browser would ignore not only an undimensioned OBJECT but also all subsequent dimensioned ones.

But in November 1997, a year after the World Wide Web Consortium (W3C) officially recommended PNG for web use, Netscape released Navigator 4.04 with native PNG support--that is, it was at last capable of displaying PNG images referenced in HTML IMG tags without the need for a third-party plug-in. Unfortunately, versions 4.04 through 4.51 had no support for any type of transparency, nor did they support gamma correction, and their handling of OBJECT tags remained broken. At least a few of these releases, including 4.5, had a bug that effectively caused any PNG image served by Microsoft Internet Information Servers to be rendered as the dreaded broken-image icon. (I'll come back to this in the server section later in this chapter, but the bug is fixed in Navigator 4.51.) But the 4.x versions did support progressive display of interlaced PNGs, at least.

Concurrent with the later Communicator 4.0 releases, on March 31, 1998, Netscape released most of the source code to its development version of Communicator, nominally a pre-beta version “5.0.” Developers around the world promptly dug into the code to fix their favorite bugs and add their pet features. One nice surprise was that the so-called Mozilla sources already contained a minimal level of transparency support. There were two main problems with it, however: the transparency mask for all but the final pass of interlaced images was scaled incorrectly--a minor bug, hardly unexpected given the early stage of development--and the transparency was either fully off or fully on for any given pixel, regardless of whether multilevel transparency information (an alpha channel) was present. The latter problem proved to be more serious than it sounded. Because of the way Mozilla's layout engine worked, at any given moment the code had no idea what the background looked like; instead, it depended on the local windowing system to composite partly transparent foreground objects with the background image(s). In other words, adding full support for alpha transparency was not something that could be done just once in the image-handling code, but instead required modifying the “front end” code for each windowing system supported: at a minimum, Windows, Macintosh, and Unix's X Window System, plus any new ports that got added along the way.

Difficult as it may sound, fixing Mozilla's (and therefore Navigator's) support for PNG alpha channels is by no means an insurmountable challenge. But in one of life's little ironies, the person who initially volunteered to fix the code, and who thereafter nominally became responsible for it, also somehow agreed to write this book. Alas, when push came to shove, the book is what got the most attention. :-) But all is not lost; by the time this text reaches print, full alpha support should be well on its way into Mozilla and then into Navigator 5.0 as well.

Table 2-1 summarizes the status and level of PNG support in all of the major releases of Netscape's browser to date. The latest public releases, Navigator 4.08 and 4.51, are available for Windows 3.x, Windows 95/98/NT, Macintosh 68k and PowerPC, and more than a dozen flavors of Unix; the web page is at http://home.netscape.com/browsers/. Version 4.04 for OS/2 Warp is available only from IBM's site, http://www.software.ibm.com/os/warp/netscape/.

Table 2-1. PNG Support in Netscape Navigator and Mozilla

Table 2-2 summarizes the PNG support in a number of third-party plug-ins. Note that the Windows QuickTime 3.0 plug-in installs itself in every copy of Navigator and Internet Explorer on the machine, taking over the image/png media type in the process. This effectively breaks the browsers' built-in PNG support (if any) and may be true of other plug-ins as well. To remove the QuickTime plug-in from a particular instance of a browser, find its plug-ins directory--usually called Plugins--and delete or remove the file npqtplugin.dll (or move it elsewhere).

Table 2-2. PNG Support in Netscape Plug-ins

Netscape's online programming documentation for plug-ins may be found at http://developer.netscape.com/docs/manuals/communicator/plugin/. The PNG Live plug-in, versions 1.0 and 2.0b5, is available from http://codelab.siegelgale.com/solutions/png_index.html and http://codelab.siegelgale.com/solutions/pnglive2.html, respectively.[14] Apple's QuickTime is downloadable from http://www.apple.com/quicktime/. Rasca Gmelch's PNG Magick plug-in is available from http://home.pages.de/~rasca/pngplugin/, and the ImageMagick home page is at http://www.wizards.dupont.com/cristy/ImageMagick.html. And Giorgio Costa's OS/2 plug-in can be downloaded directly from http://hobbes.nmsu.edu/pub/os2/apps/internet/www/browser/npgpng09.zip.

2.1.2. Microsoft Internet Explorer

Microsoft's web browser lagged Netscape's in features and performance through its first two major releases, but with the release of Internet Explorer 3.0, general consensus was that it had largely caught up. IE 3.0 was the first Microsoft release to include support for Netscape-style plug-ins and, in that manner, became the first release to support PNG in any way--though only on the Windows platform. But with the release of the first IE 4.0 beta in the spring of 1997, followed by the official public release of version 4.0 in October 1997, Microsoft took the lead from Netscape, at least in terms of PNG support. IE 4.0 for Windows incorporated native PNG support, including progressive display, gamma correction, and some transparency. The latter was an odd sort of binary transparency, however, and apparently applied only to RGBA-palette images; images with a full alpha channel were rendered completely opaque, always against a light gray background. For palette images, IE's threshold for deciding which pixels were opaque and which were transparent was not set at 0.3%, as the PNG specification somewhat unfortunately recommends, nor at 50%, as one might intuitively expect, but instead at something like 99.7% opacity. That is, unless a given pixel were completely opaque, IE 4.0 would render it completely transparent. Needless to say, this resulted in some odd and unintended rendering effects that could have been mitigated by dithering the alpha channel down to a binary transparency mask.

Internet Explorer's handling of PNG images in HTML 4.0 OBJECT tags is decidedly buggy. Like Navigator, it will fail to render an OBJECT PNG with its native code, instead preferring to seek an ActiveX plug-in of some sort. But IE 4.0 does not necessarily limit itself to its own plug-ins; it has been observed to adopt Netscape plug-ins from elsewhere on the computer, and since it apparently doesn't support the Navigator 4.0 plug-in API, it fails on newer plug-ins such as PNG Live 2.0. Even worse, when two (or more) OBJECTs are nested, IE 4.0 will attempt to render both images.

It is also noteworthy that Internet Explorer 4.0 cannot be used to view standalone PNG images, even though it can do so if the images are embedded within a web page with IMG tags. Presumably this was simply an oversight, but it has ramifications for setting up the PNG media type within the Windows registry.

Internet Explorer 5.0 for 32-bit Windows was released in March 1999, and in most respects its PNG support was unchanged from version 4.0. The inability to view standalone PNGs was fixed (allowing IE 5.0 to be used as an ordinary image viewer), but in all other regards PNG support appears to have stagnated. OBJECT PNGs are still only displayed if the “Run ActiveX Controls and Plug-ins” setting is enabled (under Tools → Internet Options → Security), even though it ends up using the same internal PNG code as it does for IMG PNGs. Even worse, OBJECT PNGs are given a fat border, which results in the appearance of horizontal and vertical scrollbars around each one, and there is no transparency support at all for OBJECTs. As in IE 4.0, nested OBJECTs are all rendered, side by side. With ActiveX disabled, IE 5.0 does revert to whatever IMG tag is inside the OBJECTs, but not before it pops up one or two warning boxes every time it displays such a web page. Its transparency support is unchanged; only palette images are displayed with transparency, and the threshold for complete transparency is still set at 99.7% opacity.

Fortunately for Mac users, the development of Internet Explorer for Macintosh is handled by a separate group, and the yet-unreleased version 5.0 reportedly will have complete support for alpha transparency in PNG images. Of course, in the meantime, Mac fans are stuck with version 4.5, which has no PNG support at all.

Official releases of IE 5.0 exist for Windows 3.x, Windows 9x/NT, and two flavors of Unix (Solaris and HP-UX). PNG support in the Unix and 16-bit Windows versions is reported to be similar to that in the 32-bit Windows version.

Table 2-3 summarizes Internet Explorer's level of PNG support to date. The Internet Explorer home page is currently at http://www.microsoft.com/windows/ie/.

Table 2-3. PNG Support in Internet Explorer

2.1.3. Opera

Opera, the small-footprint, high-speed browser from Norway, is by some measures[15] the third most popular browser for the Windows 3.x and 95/98/NT platforms. Native ports to the Amiga, BeOS, Macintosh, OS/2, Psion, and Unix are also underway. Version 3.0 had no PNG support at all, while version 3.5 supported it only through old-style Netscape plug-ins (i.e., with no transparency support). Version 3.51, released in December 1998, includes native PNG support. Opera displays PNG images progressively and does gamma correction, but like Navigator, it does not invoke its internal image handlers for images in OBJECT tags. Transparency, unfortunately, is only partly supported. Truecolor and grayscale images with alpha channels are rendered completely opaque; most palette images are rendered with binary transparency, although at least one palette-based example exists in which the image is rendered without any transparency.

Opera is available from the Opera Software home page, http://www.operasoftware.com/. News on the non-Windows ports can be found at http://www.operasoftware.com/alt_os.html.

2.1.4. Acorn Browse

At the other end of the popularity spectrum--at least to judge by overall statistics–lies a browser unique in its stellar support for PNG features: Acorn Browse. Available only for Acorn computers running RISC OS, Browse has always supported PNG and has offered full gamma and alpha-transparency support since version 1.25. Not only that, but (take a deep breath now) it actually supports full alpha transparency while doing replicating (blocky) progressive display of interlaced PNGs on top of arbitrary backgrounds. That's quite a mouthful, but in simple terms it means that the browser can display, in a very elegant manner, transparent, interlaced PNGs as they download. From a programmer's perspective it's even more impressive: consider that an opaque pixel from an early interlacing pass may get replicated and thereby hide background pixels that, due to transparency, should be visible when the image is completely displayed. So extra work is necessary to ensure that parts of the background covered up by early interlacing passes are still available for compositing during later passes. As of early 1999, there was no web browser in the world with better PNG support than Browse. Unfortunately, most development on Browse itself ended late in 1998, as a result of restructuring at Acorn; version 2.07 is the latest and possibly the final release, although the web page (http://www.acorn.com/browser) indicates that development “will continue...as a ‘spare time’ activity.”

2.1.5. Arena

Arena was the World Wide Web Consortium's early test bed for HTML 3.0 and Cascading Style Sheets (CSS1). It also became one of the first browsers to support alpha transparency in PNG images (possibly the very first), although this feat was somewhat diminished by the fact that it didn't support background images at the time--except for its own “sandy” background. Nevertheless, it was a useful browser for testing PNG images under Unix.

Subsequent to the release of beta-3b in September 1996, Arena development was taken over by Yggdrasil Computing, which managed roughly 60 beta releases over the course of 16 months. The browser never achieved 1.0 status, however, and development essentially ended in March 1998 (though a final 0.3.62 release with minimal changes showed up in November 1998). Yggdrasil's Arena web page is at

http://www.yggdrasil.com/Products/Arena/, and old versions are still available from the W3C's page at http://www.w3.org/Arena/.

2.1.6. Amaya

Amaya replaced Arena as the W3C's test-bed browser in 1996 and has always included PNG support. Unlike Arena, it runs under not only various flavors of Unix, but also Windows 95, 98, and NT. Although it supports transparency, its implementation was still somewhat broken as of version 1.4; under Linux, it appeared to support only binary transparency, and that only for palette-alpha images (that is, images whose palette effectively consists of red, green, blue, and alpha values). Amaya 1.4's support for gamma correction also appeared to be incorrect but at least partially functional. On the positive side--and not surprisingly--it handled OBJECT image tags completely correctly, including those with other OBJECTs nested inside. Amaya is freely available for download from http://www.w3.org/Amaya/.

2.1.7. Other Browsers

PNG support in other browsers varies considerably by platform. On the Amiga, it is ubiquitous, thanks to a technological marvel known as datatypes (a kind of super-DLL that, among other things, provides generic image support); but under operating systems like BeOS or Atari TOS, it is virtually nonexistent. The following sections list many of the known PNG-supporting browsers, sorted by platform.

2.1.7.1. Amiga

Two datatypes provide PNG support for virtually every Amiga browser in existence: Cloanto's (http://www.aminet.org/pub/aminet/util/dtype/PNG_dt.lha) and Andreas Kleinert's (http://www.aminet.org/pub/aminet/util/dtype/akPNG-dt.lha). Cloanto made their first version of available within months of the PNG specification freeze, thereby making the Amiga the very first platform to support PNG in web browsers. Andreas's datatype at one time was considered to have better overall PNG support, but the two datatypes appear to have comparable features as of early 1999. Unfortunately, the datatype architecture itself currently precludes alpha transparency and progressive display, but an operating system upgrade due in the second quarter of 1999 is expected to add at least alpha support.

In the meantime, there are three Amiga browsers with native PNG support in addition to basic datatype support: AWeb (http://www.xs4all.nl/~yrozijn/aweb), iBrowse (http://www.hisoft.co.uk/amiga/ibrowse), and VoyagerNG (http://www.vapor.com/voyager). The first two claim to support transparency, possibly including full alpha support. AWeb also does gamma correction, and all three display PNGs progressively as they download.

2.1.7.2. Acorn

In addition to Browse, PNG is also supported on the Acorn platform by ANT Fresco (http://www.ant.co.uk/prod/inetbroch/fresco2.html/), ArcWeb (http://www.dsse.ecs.soton.ac.uk/~snb94r/arcweb), and DoggySoft's Termite (http://www.doggysoft.co.uk/trweb.html/) and Webite (http://www.doggysoft.co.uk/prog4.html#web/) browsers, although the latter two do so via a third-party helper application called Progress from David McCormack (http://www.atlantic.oaktree.co.uk/software/termite/progress.html/). Fresco is also notable as the browser chosen by Oracle for its network computer.

2.1.7.3. BeOS

As of this writing, the best bet for a PNG-capable web browser running under BeOS is a toss-up between the upcoming Opera port to BeOS, which will presumably include Opera Software's recently added PNG support, and the upcoming release of BeOS R4.5 and NetPositive 2.1 (http://www.be.com/beware/Network/NetPositive.html/). The latter is Be's bundled web browser, which in its beta version already supports PNG--though not alpha transparency or gamma correction. BeOS R4.5 will ship with a PNG “Translator,” which is the BeOS version of the Amiga datatype concept.

2.1.7.4. Macintosh

Surprisingly enough, given the Mac's popularity among graphic designers, there are only four PNG-supporting browsers for the platform, as of early 1999. That Netscape Navigator is one of them, and that Internet Explorer is also available (though without PNG support until version 5.0 is released) presumably has a great deal to do with this lack of other PNG support. Aside from Navigator, the only known PNG-supporting Macintosh browsers are iCab, Spyglass Mosaic, and versions 3.0A1 and later of NCSA MacMosaic, and development on both of the Mosaics ceased in 1996. iCab is a promising new browser for both Classic and Power Macintoshes; as of this writing, it is still in beta (Preview 1.3a) and has no gamma support or progressive display of interlacing, but it is reported to support alpha transparency. It is available from http://www.icab.de/.

There are also two or three plug-ins for Mac versions of Netscape prior to 4.04, depending on how one counts: the PNG Live 1.0 plug-in for PowerMacs, Sam Bushell's (beta) plug-in, and Apple's QuickTime 3.0 plug-in. Since Sam Bushell was also responsible for PNG support in QuickTime 3.0, it may be considered the successor to his own plug-in.

2.1.7.5. NeXTStep/OpenStep

Only one currently available browser for NeXTStep and OpenStep supports PNG natively: OmniWeb, versions 2.0 and later, available from http://www.omnigroup.com/Software/OmniWeb/. OmniWeb displays interlaced images progressively and does full gamma correction, but version 2.0 has no support for alpha transparency. (Version 3.0 is still in beta as of February 1999; its release notes do not mention PNG or alpha transparency.) Another NeXT browser, NetSurfer 1.1, once supported PNG, but it is no longer available.

2.1.7.6. OS/2

Until mid-1998, the options for native OS/2 PNG-supporting browsers were almost nonexistent: they included a widely distributed plug-in from Giorgio Costa and a beta plug-in from Panacea Software that was available for only two weeks. These could be used with IBM's OS/2 port of Netscape Navigator 2.02. (IBM's own WebExplorer browser never supported PNG in any way.) But September 1998 saw the public release of IBM's Navigator 4.04 port (http://www.software.ibm.com/os/warp/netscape), which includes native PNG support.

2.1.8. Client-Side Workarounds: The OBJECT Tag

Suppose that we would like to use PNGs wherever possible but still allow older browsers to see JPEGs or GIFs. Is there a way to do this? The answer is either “sort of” or “yes,” depending on the approach one takes. In Chapter 1, “An Introduction to PNG”, An Introduction to PNG, I mentioned a client-side approach involving the HTML 4.0 OBJECT tag, but I also noted that neither of the Big Two yet handles such things correctly, and earlier in this chapter I enumerated some of the specific problems in the two browsers. The other approach is a server-side method involving content negotiation. We'll come back to that one later.

First, let us take a closer look at the client-side method. HTML 4.0's OBJECT tag was designed to be a generalized replacement for the HTML 3.2 IMG and APPLET tags and for Netscape's EMBED tag. Since OBJECT is a container, it can contain other elements inside it, including nested OBJECTs. The rules for rendering them are simple: start with the outermost OBJECT; if you can render that, do so, and ignore what's inside. Otherwise, continue peeling back the outer layers until you find something that can be rendered.

In the case of images, the following two elements are equivalent:

<IMG SRC="foo.png"
  ALT="[This text is visible if the image is not rendered.]">
<OBJECT TYPE="image/png" DATA="foo.png">
   [This text is visible if the image is not rendered.]
</OBJECT>

Because OBJECTs can be used for many things, the image/png MIME type in this example is strongly recommended so that the browser can unambiguously identify the data as an image (rather than, say, a Java applet) and, if it knows it has no support for the type, avoid contacting the server unnecessarily. For JPEGs or GIFs, the MIME type would be image/jpeg or image/gif, respectively. Both IMG and OBJECT tags may include optional HEIGHT and WIDTH attributes, but as we noted earlier, Netscape requires them in order to invoke an image-handling plug-in for an OBJECT tag.[16]

The trick that should allow both OBJECT-recognizing browsers and pre-OBJECT browsers to render something sensible is to wrap a GIF or JPEG version of an image, referenced via an old-style IMG tag, inside a new-style OBJECT tag that references a PNG version of the same image. In other words, one does something like the following:

<OBJECT WIDTH="160" HEIGHT="160" DATA="foo.png" TYPE="image/png">
   <IMG WIDTH="160" HEIGHT="160" SRC="foo.jpg"
    ALT="[rare photo of the incredible foo]">
</OBJECT>

If we decide to accommodate only browsers that support either OBJECT or PNG (or both) but don't care about older browsers that support neither, we can get a little fancier with nested OBJECTs:

<OBJECT WIDTH="160" HEIGHT="160" DATA="foo.png" TYPE="image/png">
<OBJECT WIDTH="160" HEIGHT="160" DATA="foo.jpg" TYPE="image/jpeg">
   <IMG WIDTH="160" HEIGHT="160" SRC="foo.png"
    ALT="[rare photo of the incredible foo]">
</OBJECT>
</OBJECT>

A browser that implements both PNG and HTML 4.0 will render the outer OBJECT PNG; one that implements HTML 4.0 but not PNG will render the inner OBJECT JPEG; and one that implements PNG but not HTML 4.0 will render the innermost IMG PNG. (And, of course, a browser with no image support will render the text in the IMG tag's ALT attribute.)

The reason these tricks don't work in practice is that some browsers--particularly Netscape Navigator and Microsoft Internet Explorer, but undoubtedly others as well--added incomplete or incorrect support for OBJECT before the HTML 4.0 specification was formally approved in December 1997. As I've already noted, no released version of either of the Big Two browsers would invoke its native image-handling code when it encountered an OBJECT image, even as late as February 1999. Navigator always renders the inner IMG unless a plug-in is available; MSIE either pops up an error box claiming to need an ActiveX control or, in our tests, manages to crash while invoking a Netscape PNG plug-in installed elsewhere on the system. (I've also noted that Internet Explorer attempts to render all OBJECTs in a nested set, not just the outermost one.) Older versions of both browsers, and, likewise, all versions of Opera to date, behave as expected and simply ignore OBJECT images.

2.2. WWW Servers

On the server side of things, PNG support is much less of an issue. With one notable exception, server-side support involves, at most, adding a single line to a text configuration file and restarting the server to have it take effect. Smoothly upgrading web pages to use PNG images if possible--i.e., enabling content negotiation--requires additional effort, however.

2.2.1. “Standard” Servers

The first requirement for a web server to support PNG properly is to enable the correct MIME type, image/png. On most servers, including CERN/W3C (http://www.w3.org/Daemon/Status.html/), NCSA (http://hoohoo.ncsa.uiuc.edu), Apache (http://www.apache.org), Zeus (http://www.zeus.co.uk/products) and various flavors of Netscape servers (http://home.netscape.com/servers), this can be accomplished most easily by editing the mime.types file to include one of the following two lines:

image/png png

or:

type=image/png exts=png

The latter format is used by Netscape servers, but for any server, the correct format should be obvious from the other entries in the file (search for the image/gif or image/jpeg lines and use one of them as a template). Apache can also be configured via its srm.conf file (or, if AllowOverride FileInfo has been specified, in .htaccess files in individual directories) with the following line:

AddType image/png png

Note that the original PNG media type, image/x-png, has been obsolete since image/png was officially registered in October 1996. If the older type is present in either configuration file, change it to image/png or delete it altogether.

Once a change to the configuration files has been made, the server will need to be signaled to reread them. For some Unix servers, this can be done via the kill -HUP command, but restarting the server is a more portable method. Check the server's documentation for the recommended approach.

2.2.2. Internet Information Server

Microsoft's Internet Information Server (IIS) marches to its own drummer. Available as part of Windows NT Server (http://www.microsoft.com/ntserver/web), IIS uses the Windows registry in lieu of the traditional text-based configuration file for media (MIME) types. This part of the registry can be modified via Explorer to add the image/png type as follows; type the text printed in italic:

1. Open Windows Explorer (Start button → Programs → Windows Explorer).
2. Select View → Options.
3. Click on the File Types tab.
4. Click on the New Type... button.
5. Enter the following information:
   • Description of type: Portable Network Graphics image
   • Associated extension: .png
   • Content Type (MIME): image/png
6. Click on the New... button.
7. Enter the following information:
   • Action: Open.
   • Application used to perform action: your full path to an image viewer.
   • Uncheck Confirm open after download box.
8. Click on the OK button.
9. Click on the Close button.
10. Click on the Close button.

Since this setup takes place on the server itself, the application associated with the media type is not particularly important; it merely enables someone sitting at the server console to double-click on a PNG image to view it. The app can be any PNG-aware image viewer, including Netscape Navigator, but (as I noted before) not Microsoft's own Internet Explorer 4.0.

Setting up the media type is all that is required for basic, standards-compliant operation, but due to a bug that appears to exist in all PNG-supporting versions of Netscape's browser prior to 4.51 (and also due to particularly strict syntax checking on the part of Microsoft's server), IIS by default will refuse to serve PNG images to versions of Navigator up through 4.5. Instead, it returns an error (“HTTP/1.1 406 No acceptable objects were found,” similar to the “404 Not found” error that is familiar to many web surfers), which Navigator renders as its broken-image icon. The cause is apparently a broken header that Netscape clients send as part of their HTTP content negotiation with the server:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg image/png

Note the missing comma after image/pjpeg. Because of this error, IIS does not recognize that image/png is an acceptable media type, and it therefore returns an error message instead of the image.

Reportedly, there is some form of workaround that involves tweaking the IIS-related parts of the Windows registry on the server, but as of early 1999, no one has yet come forth with the magic information. Semi-informed guesses include the possibilities of relaxing the strict HTTP syntax checking or of turning off content negotiation altogether, but it is not known whether either of these options actually exists in the server.[17]

2.2.3. Server-Side Workarounds: Content Negotiation

Serving PNG images with the correct MIME type is one thing, but there remains the issue of when to serve PNG images. As discussed earlier, the client-side method involving OBJECT tags really doesn't work very well. The only option that works is content negotiation, and, unfortunately, this only works for those who have control of the web server itself. Content negotiation is also dependent on the web server software being used. But it's conceptually a clean solution, and it has been proven in the field: the World Wide Web Consortium has successfully implemented it at http://www.w3.org since 1996. We'll take a look at how to enable and use content negotiation on the most popular web server in the world: Apache.[18]

2.2.3.1. Apache variants files

Apache actually supports two methods of content negotiation. The first involves “variants” files and is implemented in Apache's mod_negotiation module. To enable the module, the following line must be added to the httpd.conf configuration file:

AddHandler type-map var

The server must be restarted for this line to take effect. Then, for each image that is to be negotiated, create a .var file corresponding to the filename and refer to that in the HTML file. For example, to serve either tux.gif or tux.png, depending on each browser's capabilities, create a file called tux.var in the same directory and refer to it in the IMG tag in place of the actual image filename:

<IMG SRC="images/tux.var" ALT="[His Penguinness, Tux]">

The contents of tux.var should look something like this:

URI: tux.png
Content-Type: image/png;qs=0.7

URI: tux.gif
Content-Type: image/gif;qs=0.4

Each variant has a corresponding block of information, separated from that of the other variants by blank lines. The actual image filenames are given on the URI lines, and their corresponding MIME types are given on the subsequent Content-Type lines. In addition, a quality of source parameter qs is included for each image type. This is a number between 0.0 and 1.0 that indicates the relative preferences of the author for each image type. In this example, I've indicated that the PNG image (0.7) is preferred over the GIF (0.4). The default value of the qs parameter is 1.0.

A client browser requesting an image from the server also indicates its relative preferences, either explicitly or implicitly, via the HTTP Accept header. The web server then multiplies its quality parameter for each MIME type by the client's quality parameter [19] to get a composite value--this is the resolution phase of the negotiation. The highest composite value determines which image is sent.

In practice, things are a bit more complicated for the server, but this is usually hidden from the user. The problem arises when the client browser sends incomplete or even incorrect information. For example, some browsers send Accept: image/* , indicating that they can render any type of image. Others specify a list of image types but also include the catchall type */*. And only rarely does a client include preference values for each type. As a result, the server must assume preference values for the client. By default, all types are given a value of 1.0, but Apache “fiddles” the values for wildcard types: image/* or text/* are assigned the value 0.02 instead, and */* is assigned the value 0.01.

The variants file approach allows fine-grained control over every image in a web site, and has the distinct advantage that a site designer can use it at will, if the server administrator has enabled content negotiation. But maintaining parallel sets of images can be enough trouble all by itself; having to maintain a unique variants file for every image is enough to drive most site maintainers to distraction. Fortunately, Apache provides a partial alternative: MultiViews, a directory-wide (and potentially server-wide) method based on file extensions.

2.2.3.2. Apache MultiViews

Enabling MultiViews in Apache is accomplished by including it on an Options line in the httpd.conf configuration file:

Options +MultiViews

The option may appear inside a <Directory> container, in which case it applies only to the named directory tree rather than the entire server; inside a <VirtualHost> container, in which case it applies only to a given virtual hostname; or, if AllowOverride Options has been specified, within .htaccess files in individual directories. As with variants, the server must be restarted before changes to the main configuration file are noticed.

Once MultiViews is enabled for a given directory--say, /www/htdocs/images--a request for a file foo in that directory will either return foo if it exists or else negotiate between all foo.* files. So to serve either tux.png or tux.gif for example, simply include both in the directory and refer to them as follows:

<IMG SRC="images/tux" ALT="[His Penguinness, Tux]">

Unfortunately, MultiViews has one great weakness: no version of Apache through 1.3.3 supports multifile quality-of-source settings. [20] In particular, there is no way to add a line or two to one of the top-level configuration files to indicate that all PNGs on the site, or all in a particular directory tree, should have a source quality of, say, 0.7. Individual variants files are still allowed, and if found, their settings will override the Apache defaults. But the requirement to generate one variants file for every image is just as painful with MultiViews as with the standard variants file approach. The only alternative for now is to hack the source, which is precisely what was done at http://www.w3.org/, the home of the W3C. The W3C programmers are working to get their patches cleaned up and incorporated into the stock Apache source tree, but there is no word on when that will occur, and in the meantime, the Apache developers “have no firm plans to add such functionality.” As with many such things, multiple user requests for the feature would probably make a difference in the development plans.

[13] Applications Programming Interface, the means by which one piece of code (in this case, the plug-in) talks to another (in this case, the browser). APIs are also how programs request services from the operating system or the graphical windowing system.

[14] The codelab site went offline in March 1999, and there has been no word from Siegel and Gale whether this is permanent.

[15] BrowserWatch statistics, anyway (http://browserwatch.internet.com/stats/stats.html/).

[16] If Netscape ever modifies their plug-in code to work with IMG tags, presumably the HEIGHT and WIDTH attributes will be required there, as well. Fortunately, this is not a very onerous requirement for content producers.

[17] Another possibility (albeit a truly ugly and brutal one) is to forego the setup of the image/png media type that was described before--or, if the type already exists, eliminate it. Instead, register the .png file extension as belonging to another image type, such as image/gif or image/jpeg. But not only is this likely to break other browsers, it may not even fix the problem with Navigator; I mention it only as a last resort for desperate site administrators.

[18] The Zeus server is almost identical in configuration. See http://www.zeus.co.uk/products/zeus1/docs/guide/features/content.html for details.

[19] Multiplication is specified in the HTTP 1.1 spec; HTTP 1.0 said only to “combine” the values.

[20] Version 1.3.4 was released a few weeks before this book's deadline; the “New Features in Apache 1.3” page (http://www.apache.org/docs/new_features_1_3.html) hinted at changes relevant to a global quality-of-source feature, but I did not have time to investigate fully. Specifically, the three server configuration files were merged (srm.conf and access.conf were absorbed into httpd.conf/), and the mod_negotiation module was “completely overhauled.” A comment in the mod_negotiation source code, however, indicates that the global setting still has not been implemented.