Re: [hylafax-users] receiving: logic of RTN negative followed by MPS

[Lee Howard <faxguy@xxxxxxxxxxxxxxxx>]

Giulio Orsero wrote:

> HylaFAX-4.2.5 receiving on class1.
>
> I had a case in which:
> - HylaFAX told the remote end: MCF (confirm received OK)
> - the received tiff file was corrupt
>
> I think the sender sent 2 pages and HylaFAX put them in 1 page.
>
> Looking at the attached logs you can see:
> Sender sends 1st page
> Sender sends MPS
> HylaFAX rejects 1st page and sends RTN
> Sender sends what I think is its 2nd page
> HylaFAX confirms with MCF (and receive 1 corrupt page)
>
> So, since sender said MPS and then sent just 1 page after RTN we can assume
> sender ignored RTN; however, in this particular case maybe HylaFAX could
> have known something was wrong since it received an MPS but in the end it
> MCFed with just 1 page on hand?
>
> Since the tiff is corrupt, is there a method to clean it? I tried tiffcp w/o
> success.
> $ tiffcp -c none fax000011111.tif 1.tif
> Fax4Decode: Warning, fax000035905.tif: Line length mismatch at scanline 151
> (got 1729, expected 1728).
> Fax4Decode: Warning, fax000035905.tif: Line length mismatch at scanline 151
> (got 1882, expected 1728).
> Fax4Decode: Warning, fax000035905.tif: Line length mismatch at scanline 151
> (got 1740, expected 1728).

Part of this issue ... the part about faxgetty saving corrupt image 
files is discussed here:

 http://bugs.hylafax.org/show_bug.cgi?id=707

As for the logic part of the issue...  my opinion is that in non-ECM 
mode HylaFAX should, by default, save all pages, even pages that were 
RTN'ed.  (This was proposed years ago by Vyacheslav when the 
SaveUnconfirmedPages work was done.)  Certainly faxgetty would need to 
do a better job about cleaning up the TIFF data and ensuring that the 
data is readable by TIFF viewers.

I've actually tried to code up the save-RTNed-pages feature, but it's a 
bit messy - the current code doesn't exactly make it a simple task.  The 
code was really designed around the principle of discarding RTN'ed pages.

Now, as far as the logic involved in the fact that faxgetty *should 
know* there are two pages and not just one... yeah, I think that's very 
obvious... and this is why I think that it should save all pages, even 
RTN'ed ones.  Most non-ECM senders that get RTN from us will ignore 
it... meaning pages will be lost on reception.  On the other hand, even 
if we had saved those RTN'ed pages it's quite possible that they were so 
distorted that they would have been useless anyway.  It's one of those 
things about non-ECM fax protocol ... it just doesn't provide a good 
mechanism to ensure that each page is delivered.  A fax receiver can 
know if it's one page or more than one page if it sees MPS... but 
without examining the actual TIFF data and reading comparing it, there's 
really no extremely reliable way in the protocol to know how many pages 
(more than 1) were involved in a fax reception.

Lee.


____________________ HylaFAX(tm) Users Mailing List _______________________
 To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
 *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*