CRCL, Bankok -- HTML Techniques

SOUTHEAST ASIAN
COMPUTING AND LINGUISTICS

Produced by Doug Cooper / Center for Research in Computational Linguistics,
Bangkok. Presented in cooperation with . . . ( 0.2 -- comment only )

HOW DO WE DO IT?

Here's how these pages were produced. See the Web site software page for details on the code I wrote to keep track of things, the pixel page to learn how to do single pixel tricks, and how to give gifs transparent backgrounds, and the flame ON! page for some opinions on Web page content and design.

EDITOR -- My main HTML editor is Hot Dog, from www.sausage.com. The Web site software page has details on code I wrote to keep track of things.

I use Netscape 1.22 as my standard viewer. While I would normally be opposed to using non-standard extensions, HTML is so pitifully dumb that some kind of civil disobedience seems appropriate.

It's possible to do local previewing without running winsock.exe (and using up a comm port), which is very handy for doing demos on a notebook computer. Get and unpack mozock.zip. It has a degenerate winsock implementation, which is like a fake dll. SAVE A COPY OF THE REAL WINSOCK.DLL FIRST, then copy mozock.dll to your Windows directory as winsock.dll. Netscape will operate normally on local files.

The only bug I'm aware of is that when you get near the end of a long file, the screen rendering gets messed up (early pages printed over the current one). Anybody have a workaround for this?

PAGE BACKGROUND -- File "edgepr1.gif" is an 865-byte, 1x1200 pixel gif file with a few colored pixels at the far left. Instead of tiling, it stacks, and make the cool colored lines that go down the left size. The text is indented because it's actually the right column of a two-colum table. There's an invisible pixel (see the pixel page) of the proper width in the left column.

SOUND -- I record sound files at 8 bits/11K, and save them in compressed Microsoft / ADPCM format, which is the standard 'radio quality' .wav format. For some reason, the IMA ADPCM files were adding 'popping' noises. File sizes are about 5.5K per second. I use a cheap Microsoft sound card, but I found the standard dynamic microphone didn't have a high enough output level -- there was a lot of hum and noise on the recording. Now I use a cheap electret/condenser mike (the kind that takes a battery) instead, along with a cheap battery-powered mixer/preamp.

Normally I record using GoldWave, because it has the prettiest display. However, it won't save in compressed formats, so I open the Microsoft Quick Recorder, which does. It's easy to use the mouse to cut segments from one, then paste them into the other. I always try to "normalize" or "maximize" the volume (so that levels are similar even when recorded at different volumes), and find that it sounds better if I "fade in" and "fade out" for very short sections at the beginning and end. Please let me know if you encounter any problems.

TEXT TO GIF -- Until there is some method in HTML for specifying fonts, non-Roman text is best presented as artwork; ie. as part of a gif. My approach is to let the original application's font rendering software (along with whatever assistance Window or ATM supplies) display the text, then grab it from the backing store with a screen capture utility.

This method is a bit weaker than it might be, because you only get two-color antialiasing. However, it's done as well as it can be (which is still pretty horrible, from a typesetting point of view). Using fonts that have been designed for screen display (like MS Serif or Sans Serif) do better than fonts that are just approximations of real-world printing fonts (like Times). Another small disadvantage is that pictures larger than one screenful have to be pasted together (or presented as succesive images).

The "capture area" utility from PaintShop Pro works quite well. To produce gifs of the abstracts of my papers in PAPERS, I displayed the original 10-point text in the original WYSIWYG editor (Microsoft Word) at 100%. A line length of 5 inches is equivalent to 600 pixels, which is just about the available width of the smallest reasonable display. A five-inch line at the top and bottom makes it much easier to position the screen-capture-crosshairs, btw. After you've made the capture, reduce the color depth to 2 colors, and save as a non-interlaced gif.

In general, if you have a choice between a screen capture, and processing artwork

(eg. saving a CorelDraw file as a gif), go for the screen capture. What you see will, in fact, be what you get; and it's much easier to fine-tune onscreen. The screen capture on the right is far sharper than any save-as-gif software would produce.

THAI AND IPA TEXT -- If these are large or involved, I usually lay them out in Corel Draw, then save them as 16-gray images with transparent backgrounds as described above. Despite being the Thai edition, Windows 3.11 is not clever enough to choose the proper tone marks, so marks that fall lower or to the left must be inserted via their alt codes. Actually, I use the compose.exe TSR that comes with the SIL IPA font kit -- I've defined sequences for both the Thai and IPA tone marks.

The antialiasing (anti-jaggy) algorithm Corel uses is not very good. For relatively small text sizes, I've found that doing the originals in Word for Windows, copying to the Windows Clipboard, and finally pasting into PaintShop Pro is fairly effective. PSP will ask you how big the image should be -- you'll get a much sharper image by resizing before you paste (I assume that the TrueType renderer is doing the work). For example, the small gifs on the Thai alpabet page were sized at 150% (and saved as 1-bit gifs).

Unfortunately, the clipboard doesn't anti-alias, and does supply a variety of minor character positioning errors. Moreover, it gets confused about how much it's supposed to grab horizontally. I found that selecting a full line at a time, and then cropping after pasting into PSP, was a reasonable workaround. To get better antialiasing, smooth after pasting.

BITMAP SIZING -- In general, I lay out artwork and artistic text (as above) on an 8.5"x11" (roughly A4) page. If I keep the original to about 7 inches or less in width, then save at 100 DPI, I end up with a gif that will fit into a single page on most people's Web browsers.

Suppose the reader wants to save and print the gif? The 100 DPI version comes out too small. Bitmaps can be scaled up, but if the original has a lot of thin lines (like the keyboard gifs) they'll look pretty horrible when they're printed at 300 DPI. That's why I supply a second, 300 DPI copy too. I also povide an eps file, because it can be scaled without loss of sharpness.

All original work © 1995 Doug Cooper. Please see this disclaimer, which takes responsibility for content, and the release notice, which gives you the right to copy it. We believe that all files referenced by these pages may be distributed for research / educational purposes. If any file should not be distributed, please let us know and we will remove it.