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




Project hosted by iFAX Solutions