HylaFAX The world's
most advanced open source fax server
|
|
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
Re: [hylafax-users] fax log for all black fax
Lee Howard <faxguy@deanox.com> writes:
> >> The fax recipient of the fax associated with the following log claimed that
> >> the faxed page(s) were all black. I tried the same fax three times, and
> >> each time he said the pages were black. I ended up faxing successfully
> >> with a Canon fax machine manually.
> >>
> >> Faxing to this person isn't critical to my business, but if this log helps
> >> indicate a protocol bug in HylaFAX...
> >
> >I don't think that's protocol bug.
>
> Why would it work fine with the manual faxing on the Canon and not via
> HylaFAX, then?
>
> ....
> >.. and now we see why. It seems to be that *very* rare case, when RTN means
> >sudden line quality degradation and is not related to any protocol
> >bugs. Look, we were able to train at 14400 for the first time, but now only
> >training at 7200 has succeeded! Surely something horrible has happened to
> >the line in the meantime...
>
> Why would it be consistently bad? Would the line quality suddenly become
> degraded when using HylaFAX or my modem but not when using the manual fax?
> I just tried doing the same fax with 'ModemRate: 7200', and the log looks
> better (no 4-minute sending), but I can't say whether or not the page is
> all black.
So you always have got the same log? Then it really looks like a bug :-(
Could you post such log when the bit rate is limited by 7200 cps? I only
ask you to collect the log for absolutely the same source document. You
may even intercept intermediate TIFF (see below) and then send it directly.
> >The second page was above 200 Kbytes! No surprise, that it required more
> >than 4 minutes to send. But Hylafax itself has nothing to do with it. The
> >possible reason is that you are trying to send a grayscale image (not a
> >text). Ghostscript may rasterise it with inacceptable quality (looking
> >"black" on the other side), and moreover such images are hard to compress
> >with T.4 algorithms used for fax transmission. That's why we had so much
> >data to send.
>
> Hmm. I guess I could try sending an ASCII page to them for faxing, but
> this is the first time this has happened, and I *always* use the same fax
> client which *always* submits the fax in the same TIFF format to HylaFAX.
> Meaning, there's never a variance in the type of image that I'm submitting
> to HylaFAX (and in this case the content of the image is very typical of my
> normal faxes that I send), so why would it differ now?
Can you catch the TIFF that Ghostscript is created from your PS
document? It resides in docq directory with a name like doc1956.ps;70 until
the fax is in the send queue. Copy it to the safe place and rename to
test.tif; then use your favourite TIFF viewer to see what is really
inside. What is its size?
Hope to hear from you soon,
Dmitry
____________________ HylaFAX(tm) Users Mailing List _______________________
To unsub: mail -s unsubscribe hylafax-users-request@hylafax.org < /dev/null