CREATING HIGH-IMPACT DOCUMENTS

This document describes how to create high-impact documents for use with the
Netscape Navigator and other browsers. The concentration is on features of
the Netscape Navigator that allow document authors to significantly improve
the user experience for documents containing inlined images. Compatibility
issues with other browsers are also covered.
----------------------------------------------------------------------------

                           INTERLACED GIF IMAGES

A standard feature of the GIF image format is the option to store the image
data in the GIF file in an interlaced fashion: instead of storing the
image's scan lines in exact sequence, equally spaced nonadjacent sets of
lines are stored together, and these sets are stored in sequence. (For more
information, see page 318 of O'Reilly and Associates' Encyclopedia Of
Graphics File Formats, by James D. Murray and William vanRyper.)

Most programs that support display of GIF files, including NCSA Mosaic,
display both normal and interlaced GIFs completely properly. The Netscape
Navigator provides an additional feature: since images in Netscape are
normally decoded and displayed incrementally (as data comes in over the
network), the fact that interlaced GIFs are decoded and displayed
incrementally means that the image appears to "fade in".

In Netscape Navigator beta 0.9 and 0.91, this gives a "venetian blind"
effect as the data arrives and is displayed. As of Netscape Navigator beta
0.92 and beyond, we have adopted a great suggestion from Paul Haeberli of
Silicon Graphics and changed our code to replicate available lines of the
image during the first three (of four) decoding stages. In this way, the
user sees a complete, albeit not fully "fleshed-out" image after the first
of the four passes; subsequent passes progressively enhance the quality of
the image until, at the end of the fourth pass, the entire image is in place
at full resolution.

If you find the above three paragraphs confusing, don't worry. Just try
this:

   *  A normal (non-interlaced) GIF image.
   *  The same image, only interlaced.

If you are using the Netscape Navigator, the first image should have been
downloaded and displayed from top to bottom, and the second image should
have faded in using either the "venetian blind" effect or the "progressive
enhancement" effect, depending on which beta version of Netscape you're
using.

If you are not using the Netscape Navigator, both images should have
appeared just fine anyway.

So, assuming you find the interlacing to be a positive effect under the
NetscapeNavigator, you can convert any GIF image on your server to be
interlaced without at all affecting how other browsers view the image. Just
use one of these utilities:

   * ppmtogif has a -interlace option. So you can convert an existing GIF to
     an interlaced GIF as follows:

         cat foo.gif | giftoppm |
           ppmtogif -interlace >foo-interlaced.gif


   * More to come...

----------------------------------------------------------------------------

                                JPEG IMAGES

The Netscape Navigator fulfills a long-standing request from the NCSA Mosaic
user community and has native support for inlined JPEG images. All you have
to do is specify a JPEG-format image as the SRC value for an IMG tag, and
The Netscape Navigator will decode and display the image just as it would a
GIF image.

The big advantage of JPEG images is that the compression ratios can be much
higher for most images (particularly "real life" images). JPEG is also a
"lossy" compression method, meaning that you don't generally get the exact
same image data upon decoding that you had when you encoded the image.
During the encoding process, you can generally specify the "quality" of the
encoding. Specifying a low quality value can give you an even higher
compression ratio.

While The Netscape Navigator supports JPEG images across platforms, many
existing browsers do not support inlined JPEGs. For your documents to work
with those browsers as well as Netscape, your server will have to be smart
enough to send GIF images to non-Netscape Navigator browsers and JPEG images
only to the Netscape Navigator browsers (and other browsers that support
JPEG images -- we expect many browsers will support JPEG as a standard image
format in the near future). We will be providing information on how to do
this soon.

     (Note that HTTP's "format negotiation" support, via the request's
     "Accept" values, unfortunately generally does not give the server
     enough information to decide whether to send GIF or JPEG images to
     the client, since many browsers support sending JPEG images to
     external viewing applications and therefore tell the servers they
     support the JPEG format when they do not in fact do so internally.
     This is a sad deficiency of the current protocol and we expect it
     to be rectified in the future.)

See a comparison of a GIF image and several JPEG versions of the same image.

----------------------------------------------------------------------------

                               IMAGES SIZING

SPECIFYING IMAGE HEIGHT/WIDTH IN THE DOCUMENT
     As the Netscape Navigator is laying out a new document, it must pause
     at each inlined image and go over the network to discover the height
     and width of the image before it can continue laying out the document
     (because a properly-sized bounding box must be put in place so the
     document is laid out properly once the image is loaded). Over a network
     link with any significant latency, this can cause end-user performance
     problems relative to how quickly the document could be laid out if the
     browser knew the image's height and width to start with.

     For this reason, the Netscape Navigator allows you to specify an
     image's height and width as attributes of the IMG tag. The height and
     width are normally specified in pixels. For example, if you are
     inlining an image that is 413 pixels wide and 356 pixels high, the IMG
     tag would look like this:

         <IMG SRC="foo.gif" WIDTH=413 HEIGHT=356>

     Browsers that do not have support for the WIDTH and HEIGHT attributes
     to the IMG tag will simply ignore them and lay out the document
     normally.

     The Netscape Navigator, on the other hand, will use the height and
     width information to pop in place a properly-sized bounding box upon
     encountering the IMG tag and will continue laying out the document
     text, with no performance delay to go discover the width and height of
     the image over the network. (See the next section for details on what
     happens if the width and/or height given in the IMG tag are different
     than the actual width and/or height of the image.)

     Most general-purpose image utility programs will give you the exact
     size of an image in pixels.

IMAGE AUTO SCALING
     If you specify WIDTH and/or HEIGHT values in an IMG tag that differ
     from the actual width and/or height of the image, the Netscape
     Navigator will use the width and height values specified in the IMG tag
     and scale the actual image to fit.

     For example, if you have an image that is actually 123 pixels wide and
     78 pixels high, but you create a document that inlines the image as
     follows:

         <IMG SRC="b.gif" WIDTH=492 HEIGHT=312>

     ...the image will be scaled to fit the dimensions 492 by 312.

     This means you can purposely cause any image (GIF or JPEG) to be scaled
     to a larger size (or, for reasons I can't imagine, a smaller size) on
     the fly, by the Netscape Navigator. See an example of scaling in
     action.

     As before, browsers that do not do auto-scaling will cleanly ignore any
     WIDTH and HEIGHT attributes you add to your IMG tags and will display
     the inlined image at the normal, unscaled size.

PERCENTAGE AUTO SCALING
     The explanation of this feature is entirely in a separate document.

----------------------------------------------------------------------------

                 PERCENTAGE LOW/HIGH RESOLUTION FLIP TRICK

We have added another extension, called LOWSRC, to IMG, as follows:

    <IMG SRC="highres.gif" LOWSRC="lowres.jpg">

Browsers that do not recognize the LOWSRC attribute cleanly ignore it and
simply load the image called "highres.gif".

The Netscape Navigator, on the other hand, will load the image called
"lowres.jpg" on its first layout pass through the document. Then, when the
document and all of its images are fully loaded, the Netscape Navigator will
do a second pass through and load the image called "highres.gif" in place.
This means that you can have a very low-resolution version of an image
loaded initially; if the user stays on the page after the initial layout
phase, a higher-resolution (and presumably bigger) version of the same image
can "fade in" and replace it.

You can freely mix and match GIF (both normal and interlaced) and JPEG
images using this method. You can also specify width and/or height values in
the IMG tag, and both the high-res and low-res versions of the image will be
appropriately scaled to match.

Here are some examples:

   *  LOWSRC is a 7,752-byte JPEG; SRC is a 113,164-byte non-interlaced GIF.
     They are the same size, 360 by 398, and are not auto-scaled. Here.
   *  LOWSRC is a 16,721-byte JPEG; SRC is a 113,469-byte JPEG. They are the
     same size, 642 by 595, and are not auto-scaled. Here.
   *  LOWSRC is a 6,358-byte JPEG; SRC is a 64,714-byte JPEG. They are not
     the same size (the LOWSRC image is quite a bit smaller); the HEIGHT and
     WIDTH values of the bigger image are given in the IMG tag, causing the
     smaller image to be scaled up. Here.
   *  This one is a bit weird. LOWSRC is a 3,769-byte JPEG; SRC is a
     547,935-byte interlaced GIF. Again, they are not the same size, and the
     HEIGHT and WIDTH values of the bigger image are given in the IMG tag.
     Here.
   *  Here is a document that consists of the above four examples in
     sequence, followed by lots and lots of plain text. The objective is to
     demonstrate how the Netscape Navigator lays out all of the LOWSRC
     images and all of the document text before making the second pass
     through and loading the high-res images. Unfortunately, there may be
     problems with this theory at the moment -- they're being worked on.

If the images are of different sizes and a fixed height and width are not
specified in the IMG tag, the second image (the image specified by the SRC
attribute) will be scaled to the dimensions of the first (LOWSRC) image.
Reason: by the time the Netscape Navigator knows the dimensions of the
second image, the first image has already been displayed in the document at
its dimensions.

----------------------------------------------------------------------------

                            REAL-WORLD EXAMPLES

Here are examples of many of the techniques covered above, as seen in the
real world. Suggestions for additions to this list should be sent to
marca@netscape.com.

   *  PacMan's home page, of course, scales images all over the place.

   *  Global On-Line News and Directory Services uses interlaced GIFs
     throughout.

----------------------------------------------------------------------------

                             OTHER RANDOM NOTES

Here are some other random pointers to useful information.

   * Notes on experimental HTML extensions implemented by Netscape. As noted
     in that document, we will be working with W3C and other parties to help
     evolve Internet standards for hypermedia documents.

----------------------------------------------------------------------------

             Find out more about Netscape at info@netscape.com.
            Copyright © 1995 Netscape Communications Corporation