Conceived in 1988 by my then-partner David Droman, I perfected the first public demonstration late in that year, with commercial release in early 1989. Our first platform was the AT&T 3B2 due to our company's close relationship with AT&T, but over the years expanded to support more than thirty different UNIX platforms. I performed all those ports.

Modem Driver Development

I have been responsible for development of every modem driver ever shipped, though the company refers to these drivers as FIMs (Fax Interface Modules). From the early days on the AT&T 3B2 - with notoriously underpowered serial hardware - to supporting the fantastic high-end Brooktrout TR114 family of intelligent fax cards, my experience in class 2/2.0 fax modems and UNIX serial communications is very broad.

Though fax modems often support flow control to regular the flow of data through them, the fax protocol does not: this means that once a fax starts to arrive, the FIM must be able to accept the data at full speed. UNIX serial input queues are typically 256 bytes large, and when they overflow, the entire buffer is discarded without notice. On a busy system, this can be quite a challenge.

Furthermore, for many years, we never met a platform with a bug-free serial subsystem. Though "regular" serial terminals and printers usually worked quite well even for low-end hardware, a modem driver exercised the serial I/O system in ways that were not typical: our software was notorious for finding bugs. All of these had to be worked around, sometimes with a great deal of effort.

Our first modem was the Fujitsu dexNET 200, which was a quasi-class 3 device (lots of smarts, easy to control), and we expanded to support the outstanding modems from Multi-Tech Systems. We had an excellent relationship with the company, and (in particular) their chief fax engineer. Multi-Tech has long been the favorite vendor for UNIX class 2 fax modems due to their peerless firmware.

The port to Windows NT meant that we could then support the TR114 family of smart fax cards from Brooktrout Technology. These multichannel devices were very intelligent and offloaded a great deal of the work from the main CPU, and were able to do much better image compression and (especially) call control.

Imaging

Facsimile Data Encoders and Decoders

The actual fax data that travels over the phone line is compressed using various algorithms. The primary algorithm is the CCITT T.4 standard for Modified Huffman Group 3 encoding, and this was very compute intensive (lots of "bit banging"). I created a library of functions that performed extremely efficient encoding and decoding of this binary data, and these libraries have been essentially unchanged in more than ten years.

PostScript

VSI-FAX would accept Level 1 PostScript jobs from users, and our software would render them down to TIFF files in preparation for sending. We used the excellent "PowerPage" PostScript clone from Pipeline Associates, and I was responsible for porting and integration of this software into VSI-FAX. This integration was quite close and involved substantial involvement in the imaging and font machinery.

I was also responsible for tracking down customer imaging problems: they would find that something printed differently on their HP LaserJet than it did via VSI-FAX, and I'd get the PostScript files for research. We usually found this to be non-standard use of PostScript, but nevertheless got quite handy with debugging the language.

Character Generation

Our Epson-to-fax generator read "regular" text - with Epson-style escape codes - from the user's fax job and fully rendered the page into Group 3 fax data. We had our own font system based on the excellent Fujitsu "Roxbury" font, and I created libraries for rendering character data a line at a time.

Even though the job pages themselves were fully rendered before being submitted to the modem for transmission, the per-page headers were always done contemporaneously. Because we controlled all the bits being sent, all fax jobs sent via VSI-FAX had the same "look" in the header across the entire supported platform and modem line.

Efficient Image Printing

Modern printers use highspeed parallel ports or even faster network connections, but in the late 1980s, it was much more common for laser printers on UNIX systems to have slow (19200 bps) serial connections. The nature of fax data was that these images tended to be quite large, and the customary methods of sending images to PostScript printers expanded

I created a series of "fax fonts" that both PostScript and PCL print drivers used that drastically cut down on the time required to print an image, and our competitors never came close to our efficiencies. Eventually, faster printer channels and PostScript Level 2 support reduced our advantage, but this was a big selling point for a long time in the early years.

Technical Support

Early in the product's life, I was responsible for not only development but technical support as well, and my team routinely scored "11 out of 10" on customer surveys for satisfaction with our support. We were targetting the VAR (Value Added Reseller) market, and we knew that if our VARs knew they could count on us to help them support our product, they would actually sell our product. My team learned from me: I was never "out to lunch" for a customer if I was actually in the office to take a support call, and we knew that "technical support" was as much about "support" as it was about "tech".

Documentation and Training

[Home] Stephen J. Friedl Software Consultant Tustin, California USA