When you compose a message, you can refer to any image in web space by naming its URL. This typically generates an <a href> tag. The reader of your message doesn’t see the image displayed in the newsreader; only the link appears. This is usually the best way to handle a large image that, if shown inline, would overwhelm the message’s text. In Netscape’s composer, it’s also possible (using Insert → HTML Tag) to refer to an image using an <img src> tag, in which case the image will appear inline.

When you refer to images in either of these two ways, you need to be aware of not only the web space that is accessible to you when you create the message, but also the web space that will be accessible to readers of the message. When might those views differ? It happened to me when I moved BYTE’s private news server to the DMZ. There, it was visible from both sides of the corporate firewall. That meant that references to Internet-based images were accessible to newsreaders running either inside or outside the firewall. But references to intranet-based content were accessible only to inside newsreaders. When NNTP collaboration crosses the firewall, it’s usually better to attach or include images rather than refer to them.

You can attach any kind of image to a news message, but newsreaders (like browsers) will natively display only .GIF and .JPG formats. It’s always preferable to convert other formats to one of these. To convert to and from other bitmapped formats, such as Windows .BMP, I use JASC’s PaintShop Pro; you may favor another image editor and file-format converter. Communicator users who lack a GIF-capable graphics tool—as many people do, since the standard Windows kit doesn’t include one—can use Composer do a .BMP-to-.GIF conversion. Use Insert → Image to import a .BMP file onto the canvas, then right-click the image and use Save Image As to save it as a .GIF file.

Many vector graphics applications, such as Freehand and Visio, can export to .GIF files. Unlike bitmap-to-bitmap conversion, however, vector-to-bitmap conversion results in irreversible loss of editing capability. As in the case of an attached word processor document, you need to consider the purpose of the attachment. If it only needs to be viewed, a .GIF version is probably best, because viewing requires no additional software. If it needs to be edited, you’ll have to attach the native version. For a mixed audience, it may make sense to attach both versions.

If you use Communicator’s message composer, you can attach an image in a variety of ways:

If you use the Outlook Express message composer, there are two methods:

Note that while Netscape’s composer can also accept an image dragged from a browser, the result is not an attached image but an included image.

You can also include images in HTML news (or mail) messages. Unlike attached images, which are enumerated at the end of messages, included images appear inline. They can have titles and captions; they can be centered; they can appear in table cells; text can wrap around them.

If you use Communicator’s message composer, there are three ways to include an image:

If you use the Outlook Express composer, there is only one method: use the toolbar’s Insert Picture function, then specify or navigate to the image file.

How do you decide whether to include or attach? Include when you need to present the image in a surrounding context—near related text, or with a title and caption, or in a cell of a table. Attach when the image is too large to work well in context. You should also attach when there is no relevant context and the main reason for attaching is to transfer the image data as a file. Why? Both newsreaders can save an included image as a file, but the semantics of saving attachments are more familiar to people.

Note that a news message that displays included images works quite differently from a news message (or web page) that displays images by reference. A message with included images is a kind of self-contained compound document. View the source of such a message (as you can do in the Netscape newsreader) and you’ll see that it’s a multipart MIME message containing a region of base64-encoded text for each included or attached image.

This aggregation of text and image data into a single package can be very useful. If you use conventional web technology to collaborate on a document made of words and pictures, you have to create an HTML file that refers to separate image files. Then you have to collect all the parts, perhaps into a Zip archive, and transmit the archive to others who in turn must unpack it in order to use what you sent. In this respect, HTML-enriched mail and news clients marry the convenience of HTML with the compound-document features of Microsoft Word.

We’ve seen how URLs that you cite in a plain-text news message will become active—that is, clickable—to readers of your message. The same holds true in HTML mode. Both the Netscape and Microsoft composers will convert the text of a URL into a link. By default, the link’s label and its address are the same. So if I write “http://udell.roninhouse.com/”, the resulting HTML message contains <a href="http://udell.roninhouse.com/">http://udell.roninhouse.com/</a>.

URLs always break if misspelled. Avoid typing them. There’s no time to do so anyway. The value of providing a link in a routine conference message may not be worth the time it takes to write it. So cut and paste URLs whenever possible; don’t retype them. What about complex CGI-style URLs? In a text-mode message, these sometimes line-wrap and fail to render as clickable links. That’s not a problem in HTML mode, though.

The easiest way to compose a link is to drag one from a browser, mailer, or newsreader window and drop it onto a message you are composing. This method also yields a link that is labeled rather than raw—for example, Jon’s home page instead of http://udell.roninhouse.com/. Use of such a link requires an HTML-aware viewer, but I’m assuming here that you are operating in a group that unanimously meets that requirement. Remember, though, that this link-dragging method works best in Collabra. When you drag a link into the Outlook Express composer, it turns the text of the link into an attachment to your message.

You don’t have to accept the label that comes with a link. In both the Netscape and Microsoft composers, the label is an editable property of the link. Why change it? The existing label may poorly describe the link’s target or may poorly represent your intended use of it. Is it worth the time it takes to rewrite the label? If you’re writing a message that will be seen by a few people and then forgotten, don’t bother. If you’re writing for a larger audience, or you’re producing a document that will be bookmarked or mentioned on a web page, then you may want to beef up the quality of your link descriptions just as you would put more effort into layout and content.

Even when you correctly cite a URL, you can’t guarantee that it will always work. Servers sometimes go down; pages sometimes move. This inability to control outcomes makes some people reluctant to use links in their messages. Don’t worry. Links break all the time on real web sites; it’s not the end of the world. When you do post a broken link to your departmental newsgroup, nobody’s going to hold it against you.

If you happen to notice the problem yourself, you can cancel and repost the message with a corrected URL. What if the message has grown a subtree of responses? In that case you probably don’t want to cancel it, because that will orphan the responses. What you’d really like to do is just edit the message in place. NNTP servers don’t allow that, but if you’re curious, it can be done—see Chapter 9 for details.