HylaFAX The world's most advanced open source fax server

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hylafax future



Dear Robert,

| Thats pretty much what both whfc and response do - the problem is handling
| the fax number to be dialled.

That seems to work quite well with Respond.

| I've basically decided there are two ways to do this:

I think Method A, through Samba, is better. I've tried using both
Respond and whfc, and I've also been in touch with Uli, the author of
whfc. It appears that the message that Win95 generates to the printer
driver when a job is spooled, is unreliable. In other words, sometimes
the printer driver receives no message, and thus does not wake up. In
that case, it is unreliable, and the problem is not repeatable.

Samba seems to bind with flaky MS OS's much better. They don't seem to
show any such unreliability. The Respond program is a standalone TCP
server which seems to wake up on connect from the Samba server, again
without any problems. I've modified the printfax.pl file of Respond to
work with Hylafax instead of mgetty+sendfax. It works fine. Installing
samba on Linux is not difficult; binaries are available, with a
/etc/smb.conf. All that's needed is an appropriately modified
printfax.pl to work with Hylafax. You can use mine. (And an English
version of Respond.) This package can be bundled with a file fragment to
add to smb.conf, to take care of the Samba printer config problems.

| Method A - SMB, Samba method - You need to setup the server to run Samba to
| do SMB networking, setup a SMB shared directory ie \\HylaServer\fax which
| contains some special files through which server and client communicate ie
| FIFOs sort of like /proc under linux(MS-Fax and response use this method)

I think this description that you've given is more complex than needs to
be. If you use printfax.pl, you just need to define one Samba printer.
None of this "shared spool directory with special files" is needed.

I'd really love to see a good Respond program with a phone book,
together with a utility to export and import phone books from ASCII
files.

In general, all network sharing between MS computers and Unix systems is
easier done through Samba than things like NFS. We've abandoned PCNFS
completely for such apps. Samba is far more robust and works beautifully
under varying load conditions. I think future extensions like fax
printers should all be built on the Samba infrastructure. One of the
advantages of the Samba approach is that the basic MS OS does not need
to be touched. Whatever MS provides as network printer client software,
etc, all works fine as long as you don't want to write your own. With
the WHFC approach, you try to add a printer driver and it doesn't work
out that stably. With Samba+Respond, you use the MS network printer
client, and it works every time. Basically, MS OS's are flaky; you never
know what kind of Crazy Glue they use to put together their components.
Just don't try to do similar things yourself. Keep to separate,
standalone pieces like Respond, and your overall integration is more
robust.

One thing missing in Respond is the ability to cut out the first few
lines of the generated PS file. (WHFC does this.) You see, Win95 doesn't
seem to have a pure PS printer driver the way Win3.1 did. So you use HP
LJ4M, and this driver generates the first few lines of PCL to put the
printer in PS mode and do some other stuff before actually sending the
PS file. These first few lines need to be filtered out. This can be done
either by Respond (anyone feel like modifying the C code?) or by
printfax.pl; mine doesn't do it yet. Should be simple. Just strip the
first few lines, something like the equivalent of 

	(
	    echo '%!PS-Adobe-2.0'	# add a %!PS-Adobe header
	    sed '1,/^%!/d' infile 	# strip from first line to %! of infile
	) > outfile

written in Perl.

Regards, and I hope this helps someone at least.

Shuvam




Project hosted by iFAX Solutions