HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
Solved: squashed/stretched pages & format_failed
- To: flexfax@sgi.com
- Subject: flexfax: Solved: squashed/stretched pages & format_failed
- From: Jacco de Leeuw <jacco2@dds.nl>
- Date: Fri, 06 Aug 1999 12:36:05 +0200
Hi,
We have been using the hylafax-v4.0pl2 RPM (recompiled with minor
changes) on Linux RedHat 5.2. We had a couple of problems which
we seem to have been solved now, and I would like to share them with
you.
- We are using Multitech internal ISA 33K6 modems (MT2834ZPXI-022,
if I'm correct; not at the office right now). This model is not
specifically mentioned in the list so we used the Multitech
configuration file included with Hylafax. The problem was that
we sometimes received "squashed" faxes. I added some lines from the
generic Class 2 configuration file and this fixed most of the
squashing but not all of it.
- I reduced the serial port speed from 57600 bps to 38400 bps and
this solved the rest of the squashed pages problem.
- At irregular times, users who used WHFC to fax documents got the
following message:
Your facsimile job to xxxxxxxxx was not sent because
document conversion to facsimile failed. The output from the
converter program was:
Check any PostScript documents for non-standard fonts and
invalid constructs.
At first we thought that MS Office might be generating lousy
Postscript, but that could not be the cause: exactly the
same document *could* be faxed some time later. Examining the
queue directories showed that the Postscript files actually had been
converted to facsimile (G3 TIFF) alright. But Hylafax's 3 second timer
had kicked in immediately so it thought the conversion had failed.
You have to know that we used an "at" job to stop and start Hylafax,
to have it reread its configuration files. Somehow this "at" job
screws
up Hylafax alarms/signals/timers. I'm not a hard-core Unix systems
programmer so I don't know the exact cause, but at least I was able
to find out where and why the error occurred. Hurray for
source code... ;-).
Upon further examination of the source code we noticed that hfaxd
does a stat() on its configuration files so we didn't have to do a
/etc/rc.d/init.d/hylafax stop and start after all. So we removed
those. This seemed to solve the problem. Still, I don't understand
why the "at" job confuses Hylafax's timer, while a cron job doesn't.
- We use $FAX2PS -S $FILE | lpr to print out received faxes.
Note the -S switch which scales the fax to fill the page. When
large (i.e. mostly too wide) faxes were received, they were scaled
down to A4 format, which is great. However, this had a side effect:
small faxes were blown out of proportion and stretched to fill the
whole page. John Williams' patch
(http://www.hylafax.org/patches/tiff2ps.patch) seemed to fix this,
but we were using fax2ps and not tiff2ps (AFAIK both programs do
similar things but fax2ps generates more efficient Postscript output
for fax purposes). So I wrote a new patch for fax2ps (libtiff) which
only scales *down*, not up. And this separately for height resp.
width. It works for us, but perhaps one of Hylafax experts should
review it. If anyone wants the patch, just mail me.
Jacco
--
Jacco de Leeuw mailto:jacco2@dds.nl
van Wessemstr. 54 http://huizen.dds.nl/~jacco2/
1501 VM Zaandam, Holland tel:+31(0)756352068
In Windows, the power switch is an integral part of the user interface.