Posting Files of Different Filetypes (Any Filetypes!) on the Web

You can post computer files of any kind on web pages, by a method described further down this page. Mathematicians will be particularly interested in (for instance) posting their tex files, so that other mathematicians can download those files.

Of course, what the recipient does with those files after downloading them will depend on what kind of software the recipient has. If your intended audience consists of undergraduate students, you should not assume that they have any tex software; instead you should convert your tex output to gif files which they can view using plain old Netscape. See the explanation on our web page about that conversion process.

On the other hand, if your intended audience consists of other mathematicians, you can safely assume that they have some tex software, and so they can handle tex files and related filetypes. Actually, I would recommend that you post your postscript files (no pun intended), not your tex files or your dvi files. The use of tex or dvi files depends on other files that are stored locally in the computer; a file may behave in different ways when used on different computers which have different tex installation setups. There is no standard tex installation that is universally followed. In contrast, the postscript format is very much standardized; a postscript file probably will display or print in much the same fashion on two different computers.

If you do decide to post tex files, I recommend renaming them so the filenames end in "txt" rather than "tex". Every browser program knows what to do with textfiles; not every browser knows what to do with "tex" files.

Caution: In most cases, when you publish a paper in a journal, you are transferring the copyright to the journal's publisher, and you do not legally have the right to post a copy of your paper on a web page! Most academic journals presently are being generous about this, and permitting authors to post their own papers, but there is no guarantee that they will continue to take that attitude.

How to make a postscript file. Our own unix system does not automatically generate a postscript file whenever you run the tex program. Hoewever, you can create a postscript file this way: Say you've written a file called bigpaper.tex, and then you've used either the tex program or the latex program to create the file bigpaper.dvi. Then you can use the command

dvips bigpaper.dvi

to create a new file, bigpaper.ps. In most cases, if a browser does not know how to display a file, the browser will offer to download the file; presumably the person using the browser can then find some other program to display or play the downloaded file.

How to post a file. Here is a typical example. (I'll use a postscript file as an example, but the method works with any filetype.) Say you have a web page, which is coded as a file called index.html. Suppose you want to post a file called bigpaper.ps, about 1.3 megabytes long, and it's located in the same directory as your web page. Then you just need to add this line of code somewhere in your html file:

<a href="bigpaper.ps">Here is my postscript file</a> (about 1.3 megabytes)

Of course, you can word that a little differently if you wish. Mentioning the approximate filesize is optional, but I recommend it --- that way people can get some idea of how much time and disk space they'll need for downloading your file.

How does the downloading work?> Here is what will be seen by people who look at your web page:

Here is my postscript file (about 1.3 megabytes)

The underlined words are a link. When your colleague clicks on that link, one of several things could happen, depending on what browser program your colleague is using and how that program is configured:

the browser may start to download "bigpaper.ps".
the browser may start up some special program that is designed to display postscript files, and may display "bigpaper.ps" in that program.
the browser may display a message, asking whether your colleague would prefer to download the file or just display it in the special program
the browser may inform your colleague that it doesn't know how to display a postscript file, and may ask your colleague whether he/she would like to download a program that can display postscript files

What about subdirectories? Here is a slight variant of the preceding instructions. Say your html file is in a directory called "WWW", but the postscript file is in a subdirectory of WWW called "somefiles". Then you would put this line into your html file:

<a href="somefiles/bibpaper.ps">Here is my postscript file</a> (about 1.3 megabytes)

If you put Postscript files on your web page, you might want to also tell your intended audience that they can get Postscript viewer programs (for Unix, Windows, Mac, or Atari) from the UW's CS Department's Ghostscript Home Page. (Of course, this requires 10 megabytes of hard disk space, and perhaps an hour of downloading and installing. So not everyone will want to read your files if you make them available this way.)

What about compressed files? A compressed file cannot be viewed directly, but it takes less time to download. It can be posted on your web page by the same technique as that described above for postscript files. What compression method should you use? I would recommend using the "gzip" command, because most academic mathematics department computing systems are unix-based, and most unix systems have the gzip and gunzip command. This choice is not foolproof -- some of your intended audience may be using some other system -- but probably more users have access to gzip and gunzip than any other compression format.

Here is an example. The postscript file "bigpaper.ps" described above was 1.3 megabytes, which takes a fairly long time to download. You can cut that time in half, approximately, by compressing it. Use the command

gzip bigpaper.ps

This will create a file called bigpaper.ps.gz, which is shorter than your original file -- for instance, if bigpaper.ps was 1.3 megabytes, then bigpaper.ps.gz might be only 786 kilobytes. Now post it in your web page, with a line like

<a href="bigpaper.ps.gz">gzipped postscript file</a> (about 786 kilobytes)

Your colleague will see a link that looks like this:

gzipped postscript file (about 786 kilobytes)

After your colleague downloads the file, he/she can uncompress it with this command:

gunzip bigpaper.ps.gz

Further Remarks About Posting Graphics

The technique described above works for essentially any filetype. In particular, it works for image (picture) files. For instance, if you have a picture of a hyperbolic paraboloid in the file "hypara.gif", you can make it available by putting this link in your main html page:

<a href="hypara.gif">picture of hyperbolic paraboloid</a>

The picture will not be displayed on your main html page. However, the words "picture of hyperbolic paraboloid" will be displayed as a link -- i.e., underlined in Netscape, or boldfaced in Lynx. Anyone who clicks on the link will be taken to a web page consisting of just the picture and nothing else.

For image files, another technique is available: you can embed the image in any html page; that page may contain other material. For instance, you could include this line:

This picture: <img src="hypara.gif" border=5 alt="[picture of hyperbolic paraboloid]"> is a picture of a hyperbolic paraboloid.

Then the picture is displayed on the main html page; in fact, it is displayed in mid-sentence, right after the colon. A picture displayed in this fashion is called an in-line image.

The border=5 is optional; it draws a border around your picture on most graphical browsers. Omit it if you want no border -- but on a few browsers a small border may still show up. You could replace the number 5 with a larger or smaller number for a thicker or thinner border. Using border=0 also yields no border; this should work on all browsers.

The alt="[picture of hyperbolic paraboloid]" is also optional, but it is strongly recommended as a courtesy to blind people and to other users of pictureless browsers. It is the alternate text; it is displayed in lieu of the picture on any browser that does not display pictures -- such as Lynx, or such as Netscape with its images turned off. (Many people run Netscape with the images turned off, because it runs faster that way.) The alternate text is not displayed on browsers that are displaying the picture.

Avoiding long waits. Large pictures take a long time to load. You might not realize that when you're testing your own web page, because (i) you're looking at it through a local connection, not from the other side of the world, and (ii) you may have loaded those pictures before, so Netscape may have stored them in its cache and might not be reloading them at all. But someone else far away, viewing your web page for the first time, may have to wait a long time to wait for your images to load. Therefore, you generally should not use more than a handful of images on one web page, and you generally should not embed large images as in-line images.

Here is a compromise technique that many people like to use. Create two versions of your picture. Say the original, large version is called "big.gif"; it might be 500 kilobytes long. Use some graphics editor program to create a smaller version of the same picture -- e.g., "little.gif", about 40 kilobytes long. Now insert this code into your html page:

<a href="big.gif"><img src="little.gif" border=2 alt="[thumbnail of hyperbolic paraboloid]"></a>

This displays your little picture on the main html page; it is called a thumbnail picture. Anyone who clicks on the thumbnail picture will be taken to the big picture. ... When using thumbnails, I recommend including a small border, as in the example above. The border will show up in the same color as the other links on the page; this makes it more obvious that the thumbnail picture is "clickable."

Another way to reduce the loading time is to eliminate colors that you aren't actually using. For instance, if your image only uses 16 colors, then you don't need to store it in a format that is used for a million colors. The lower-level format yields a smaller filesize, which takes less time to load. Many graphics editor programs are capable of reducing the number of colors in an image file. Also, last time I looked, there was a free online service that would do this.

A VU Math web page, updated 20 Jan 2000 by webmaster. Your comments are welcome.