Chapter 2. Applications: WWW Browsers and Servers

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.

[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.

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.

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

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.

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

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.

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.

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

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.

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

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.

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.''

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

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

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:

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]

[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.

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.

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.

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]

[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.

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]

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