No Subject

[bely@stormoff.com]

σΣ: David Woolley <david@djwhome.demon.co.uk>
Subject: Re: flexfax: How stable is Hylafax 4.1 beta2 ?
References: <200004070718.IAA22025@djwhome.demon.co.uk>
From: Dmitry Bely <dbely@mail.ru>
Date: 14 Apr 2000 21:16:36 +0400
In-Reply-To: David Woolley's message of "Fri, 7 Apr 2000 08:18:09 +0100 (BST)"
Message-ID: <uu2h4y557.fsf@mail.ru>
Lines: 26
User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Big Bend)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

David Woolley <david@djwhome.demon.co.uk> writes:

> > There is a new binary planned for beta-3, which will contain the RTN fix.
> 
> It's an RTC fix, not an RTN fix; there may be other causes of RTN and its
> not even clear to me that data sent after the end of the stream should be
> acted upon by the remote fax a it could be noise as the carrier drops.

You may or may not believe, but I (and many others) have made countless
number of tests, and they show clear that RTC in TIFF file (together with
the problem of first EOL and the extra RTC send by Hylafax in Class 2.0
mode) *is* the reason of RTN (although I do not claim there are no other
RTN-related bugs in Hylafax). RTN indicates incorrect T.4 data which the
receiver cannot handle, and in this case they *are* incorrect. Welcome to
hylafax-devel mailing list :-)

> (Arguably, also, the problem is in ghostscript, not Hylafax; I wonder if the
> SGI RIP generated it.)

Two other bugs mentioned above are not TIFF writer-dependent, and they
have been present in Hylafax for several years. And all this time you (and
many many many others) were saying: "man, it's just a bad line quality
(firmware problems/whatever else)!" :-(

Hope to hear from you soon,
Dmitry