Living without Windows!by Jos Visser
Part 12: I fax, therefore I am
As business in the festive season is usually quite slow, we decided to spent Christmas and New Year's eve with my parents. Lat year, tempted by the climate and lower price levels, they sold their house in Zealand (the most south-western province of the Kingdom) and moved to a luxurious free standing patio bungalow in a tiny hamlet halfway Valencia and Alicante in the south of Spain. The weather in the Netherlands has been really awful this year: 1998 has made it to the books as the wettest year in recorded history. As you can imagine, in the Netherlands this means being soaked all year round! In contrast, reports from eye witnesses had it that the Spanish weather had been Really Great this year. When I visited my parents last June I had been able to experience this first hand, and suffered a depression for more than two weeks after I had returned. Believe me, the decision to temporarily leave the mud pool where we happen to live was not very difficult and quite quickly made. So, we packed one of our cars (the biggest) and drove across the Netherlands, Belgium, Luxembourg and France to Spain. Crossing four monetary zones did really make us wish the Euro was already here!
Obviously, being a workaholic, I took my laptop with me (much to the chagrin of both my wife Jolanda, and my mother). I imagined that during a relaxing and easy week I would be able to finish a manual for one of our products (SRAM, the OSP System Resource Availability Monitor), write a web page or two and write a column for the Software Release Magazine (I am a regular contributor and in 1999 I will write a monthly column on Java). Additionally, only the week before I had bought a book on developing Linux device drivers and I wanted to read it and perhaps write a few lines of C code.
Over the Christmas week, I took the time to do some small time configuration and modification of Linux. One of the first things I had to do was to change the script I use to dial in to the Internet. The quick hack I put together some time ago was pretty static: it only allowed dialing in to the UUNET POP in Amsterdam from an Amsterdam area (020) telephone number. If I was to read and send e-mail from Spain, I had to be able to enable long distance access by prepending a country and net number to the POP subscriber number. A few minor modifications to the script now allow me to specify where I am as a command line parameter, the script adapts the telefphone number to be dialed automatically. I intend to make it even nicer by storing separate configurations of POP, userid/password and location. The KDE comes with a quite nice graphical Dial-up networking tool, so if you use de KDE you should not run into any problems.
Before we left for the southern European shores I had requested UUNET Global Roaming so that I could dial-in to UUNET POPs outside the Netherlands. As it turned out, UUNET now allows you to remotely change your dial-in user profile through a web application, which I duly did. Once in Spain I looked up the telephone number of UUNET's Iberic Global Roaming POPs. It so happened that there was one in Valencia: only 100 km away from where I was. Unfortunately my dial-out script refused to setup a connection with that POP :-(. I tried to login manually (using "cu" and "minicom"), but even through these terminal emulator programs I could not get a clear connection. The modems shaked hands, but from then on only garbage was received. The gibberish I received gave the impression that it was something like a baud rate or parity error. However I manipulated the settings, I could not get things straight. I then concluded that it was probably a mismatch in error correction or compression settings. Unfortunately I do no know my PCMCIA modem's AT command set by heart, and I decided to give up. Fortunately, I need to connect only once a day to up- and download my e-mail. This currently takes only one or two minutes (thanks everyone for not sending big attachments :-).
Another thing I did was disabling "SuSEconfig". The nice folks at SuSE have written some software to more or less automatically maintain the system configuration based on packages installed and settings in "/etc/rc.config". When you use YaST to update or configure the system, it runs "SuSEconfig" to change the system configuration. However, I have written some scripts that modify the system configuration directly based on where I am: e.g. my "net" script changes "/etc/resolv.conf" to specify local name servers and domain name search paths'. When "SuSEconfig" runs it undoes my modifications to this and other configuration files (e.g. "/etc/host.conf"). Fortunately, the SuSE folks reckoned that their cleverness might be too much for some, and they created a facility for disabling "SuSEconfig". Specifying "ENABLE_SUSECONFIG=no" in "/etc/rc.config" does the trick. Keep in mind though that they specifically (and in my opinion rightfully) warn you not to bug them with support questions once you disabled their prime configuration tool.
As you might know, we live in a newly built house in Zeewolde, a small village recently built on the bottom of a former inland sea. Over the past year and a half, we have had heaps of trouble with the new house: delays, poor quality delivered by the builder, more delays, the town council forgetting to build the roads to our new house, even more delays, and, to top it off, 14 leaking windows and doors! Let me give you a word of warning: never let "BK Bouw" from Bussum in the Netherlands build or renovate even a shed for your dog! We received the key to our house on the 30th of September. Contractually, the builder had obliged himself to repair all defects within three months following this date. Since there are still a bunch of unsolved problems, we thought a stimulating letter might be in order. Since we were in Spain, the builder is in the Netherlands and snail mail takes over a week to arrive, we decided to send a fax.
My PCMCIA modem has fax capability (allmost all modems have nowadays) and I imagined that my Linux system should be capable of sending faxes. I started off by doing a man page lookup on the keyword "fax":
josv@jadzia:/home/josv > man -k faxAha, this looks good! A whole bunch of commands that seem to have things to do with faxing. Contrary to my nature, I started off by reading a few of these manual pages. As it turned out, users have to use a command called "faxspool" that is parameterised with the telephone number of the remote fax machine and the file to be faxed. "faxspool" tries to convert the file to the G3 format that is required by the fax protocol and creates a fax job in the "/var/spool/fax" directory. Subsequently, "faxrunq" has to be run. "faxrunq" runs the fax spool queue and calls "sendfax" for every job in the queue. So that's all there is to it! I can do this!
coverpg (1) - create a fax coverpg on stdout
fax (1) - fax sending and receiving with mgetty+sendfax
faxq (1) - display fax jobs queued by faxspool(1)
faxqueue (5) - sendfax fax spool queue control files
faxrm (1) - remove fax jobs queued by faxspool(1)
faxrunq (1) - send fax jobs queued by faxspool(1)
g32pbm (1) - convert a Group 3 fax file into a portable bitmap
pbm2g3 (1) - convert portable bitmaps (PBM) into G3 fax files
sendfax (8) - send group 3 fax files (G3 files) with a class 2 faxmodem
fax2tiff (1) - create a TIFF Class F fax file from raw fax data
g3topbm (1) - convert a Group 3 fax file into a portable bitmap
pbmtog3 (1) - convert a portable bitmap into a Group 3 fax file
pbmtosff (1) - convert a portable bitmap and produce a CAPI SFF FAX file
The fax software is parameterised by a bunch of configuration files in "/etc/mgetty+sendfax" (the fax software is part of the "mgetty" program). I used "vi" to go over the configuration files and they spoke very much for themselves. I knew my modem was at "/dev/ttyS2" and I guessed it would be a class 2 fax modem (whatever that might mean :-). I thought that before I'd send a "hot" letter I'd better first send a few samples to my office. For the first attempt I used "vi" to create a small ASCII file saying something like " Hi there, this is Jos". Then, I executed "faxspool" to send this file:josv@jadzia:/home/josv/tmp > faxspool 0031204950223 faxtestHehe! This looked good. I checked the "/var/spool/fax" directory, and there it was: the "faxtest" file, in G3 format (presumably converted from ASCII to G3 by "Ghostscript"). Ok, then for a somewhat more complex case. I fired up Applix Words and created a text document with roughly the same content. Using Applix Words' File->Print menu option I saved the file in Postscript format as "faxtest.ps". Spooling that file proved just as easy:
spooling to /var/spool/fax/outgoing/F000001...
faxtest is format: ascii
GNU Ghostscript 4.03 (1998-5-1)
Copyright (C) 1996 Aladdin Enterprises, Menlo Park, CA. All rights reserved.
This software comes with NO WARRANTY: see the file COPYING for details.
Loading NimbusMonL-Bold font from /usr/share/ghostscript/fonts/n022004l.pfb... 1889176 570128 1320168 29316 0 done.
Page height = 70.
Putting Header lines on top of pages...
Fax queued successfully. Will be sent at next ``faxrunq'' run.josv@jadzia:/home/josv/tmp > faxspool 0031204950223 faxtest.psAgain, the "/var/spool/fax" directory looked A-OK! The "faxq" command told me that two jobs were queued:
spooling to /var/spool/fax/outgoing/F000002...
faxtest.ps is format: ps
Putting Header lines on top of pages...
Fax queued successfully. Will be sent at next ``faxrunq'' run.
josv@jadzia:/home/josv/tmp > faxqHad I changed my mind, I could have used "faxrm" to remove the files from the fax queue.
F000001/JOB: queued by josv. 1 page(s) to 0031204950223.
F000002/JOB: queued by josv. 1 page(s) to 0031204950223.
Next, I changed to the "root" userid and executed "faxrunq". This command executed flawlessly, taking the jobs from the queue, dialing to my office's fax machine and pushing the fax files through the modem. I have configured the fax software to send an e-mail message to the sender whenever a fax has failed or has been succesfully sent. So once I saw "faxrunq" busy sending these files, I fired up "elm" (as "josv") and immediately found a message saying that the first fax had been succesfully sent. The next thing that happened was that Applix Mail popped up saying that a new message had arrived! Simultanously, "elm" complained that my mail box had unexpectedly shrunk by 627 bytes! How funny! Obviously, Applix (which was still running because I had used Applix Words to create the Postscript test fax) monitors my local inbox and extracts any mail appearing there into its own e-mail storage. My "elm" had just beaten it but Applix brutally nicked the e-mail from underneath "elm"! Normally I do not use Applix Mail since I do all my e-mailing with Netscape Messenger (part of Netscape Communicator). Ah well, I'll have a look at this at some later time.
Once "faxrunq" was finished I called the office to verify the correct arrival of the faxes. To my satisfaction, both faxes had arrived in perfect order! Hurrah!
Next I wondered what the fax documents looked like. I know from experience that fax quality problems are usually due to poor scanning rather than due to poor printing. Since these document had been generated and sent electronically, I reckoned that they would be all right. Due to a configuration option I had enabled, my sent fax jobs are not removed from the fax spool directory: they are merely renamed so that "faxrunq" won't bother sending them again. This meant that the G3 files that had been sent were still there. Now, I did not think I could view these files directly, so I copied them from the fax spool directory and used the "g32pbm" command to convert the G3 format file to PBM (Portable Bitmap). My idea was to then use "pbm2ps" to convert the PBM files to Postscript and view them using Ghostscript.
Unfortunately, the "pbm2ps" command did not recognise the PBM files generated by "g32pbm". I skimmed through the "pbm" manual page and found a reference to a "raw" PBM format that had to be specifically enabled in the C source. The "file" command told me that the "faxtest.pbm" file was "raw". I reckoned that "pbm2ps" could not understand the "raw" format". So, no viewing of these files through Ghostview :-(. It then dawned in me that the GNU Image Manipulation Program (GIMP) might understand "raw" PBM files. I opened the file with GIMP, et voila: there it was, including the header line that "faxspool" puts on every page. Even later, I had a brainwave to the effect that GIMP might even understand the G3 format directly. A test confirmed this suspicion. I needn't have bothered to convert the G3 file to PBM: GIMP can read and process them directly. This confirmed another of my findings of the recent months: GIMP is Great! (To the right, you see one of the test faxes I sent. Click it to get the full page version. Please pay attention to the header line which is configurable through "/etc/mgetty+sendfax/faxheader)
As usual, after having acquired some basic capabilities, there are a bunch of things I would like to do to make it a more generally useful function. In this case we're talking about the following things:
But hey, maybe something for my next vacation?
- Integrate the fax send capability in the Linux printing system, thereby making it possible to send faxes directly from any program that can print. This might mean that the printer driver should be able to pop up a window to get addressee information.
- Integrate it with an LDAP directory service to lookup fax telephone numbers.
- Implement the "make.coverpg" program. This is called by "faxspool" to generate cover pages for fax jobs. If it is not there, no cover page is sent.