Living without Windows!

Introducción

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.

Small fry

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.

Faxing

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":

Aha, 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!

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:

Hehe! 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:

Had I changed my mind, I could have used "faxrm" to remove the files from
the fax queue.

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!

Viewing the fax files

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)

To do

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:

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.