Re: [hylafax-users] Faxes cut in half

["andrew rinaldi" <andrew.rinaldi@xxxxxxxxxxxx>]

Hi Danilo,

We have a Brother MFC-890 in our test lab.  We would be happy to send you
some fax's if that would be helpful... Obviously, we can't guarantee that
the behaviour will be the same as the MFC-8600 but it might be worth a quick
test.

If you're interested then please contact support@xxxxxxxxxxxx 

Regards

ANDREW RINALDI
Mainpine Limited Support
USA +1 503 822 9944 | Asia/Europe +44 1225 869439  
andrew.rinaldi@xxxxxxxxxxxx | www.mainpine.com

-----Original Message-----
From: hylafax-users-bounce@xxxxxxxxxxx
[mailto:hylafax-users-bounce@xxxxxxxxxxx] On Behalf Of SCIN - Danilo Bottino
Sent: 01 December 2006 02:13
To: Lee Howard
Cc: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] Faxes cut in half

Thanks for the long explanation!

I did a search through the logs and found that

1) it happens with only one receiver who owns this BrotherMFC-8600 model
(also mentioned in the session log I sent some days ago), and this is good.

http://www.superwarehouse.com/images/products/printers/multifunction/brother
/brother_mfc_8600.gif

2) there are no other receivers with that model, so we can't compare the
session logs, and this is bad.

Anyway, we reached ~50 outgoing faxes a day and this is the only one
receiver who sometimes reports a badly received fax. So, you're probably
right in thinking there's a problem on his end.. ok, I'll try that
JobControl thing to see what I get! I'll keep you updated.

Danilo

> SCIN - Danilo Bottino wrote:
>
>>  I've managed to store a few of those badly received tiffs and as far 
>> as I can see the conversion looks good. Huh.. now what?
>
>
> Let me give you a run-down of the image proces - maybe it will help 
> you understand what we're after.
>
> You submit some document to the server for transmission.  The server 
> then looks at that document and "prepares it" for transmission... 
> meaning the server has an "info" file describing the known capabilites 
> of the remote device, and so it will then prepare the image according 
> to what it anticipates will work best and closest to the request of 
> the user.  If the submitted document just happens to be in the proper 
> format then the server will not do anything to the image for preparation.
>
> Then the call is placed and the remote device is contacted.  The 
> remote's feature support is examined, and if we can communicate the 
> fax image that we prepared then protocol moves ahead.  If it is not in 
> an acceptable format for the receiver then we hang up, prepare the 
> image correctly, and then dial again.  Then faxsend reads-in (to RAM) 
> each page of image data as it is needed in the protocol, and the 
> tagline is put onto it (again, in RAM).  When dealing with an MMR 
> source document this requires us to regenerate the entire page of 
> data.  When dealing with MH or MR source documents we can snip and 
> cut-n-paste the scanlines into place without modifying the rest of the 
> page.  And then, if ModemSoftRTFCC is enabled (and it is by default) 
> faxsend with convert the image compression between MH, MR, and MMR 
> (and JBIG where available) on-the-fly and then transmit that data to the
receiver.
>
> In the transmission process it can be done with or without ECM.  With 
> ECM there is a virtual guarantee that the data will be correct before 
> the receiver attempts to decode it.  Without ECM there is no guarantee at
all.
>
> The receiver then does whatever it does, but in the process it will 
> decode the image data to print it onto paper.
>
> So hopefully you can see all of the points where the image can get 
> fouled up from the point where you have the original document on file 
> and submit it to the server and the point where the receiver prints it
out.
>
> In your case you have shown me logs that indicate that the session 
> used MMR source documents and transmitted MMR (thus no RTFCC employed) 
> and that ECM is being used.  Now you're confirming that the source 
> documents are fine - at least to your TIFF viewer.  The receiver's fax 
> machine is confirming all of the ECM frames as received in good form.  
> The fact that the receiver's print-out is being truncated means that 
> at the point of truncation the MMR data it has is corrupted according 
> to its T.6 (MMR) decoder.  The fact that the corruption occurs inside 
> of the page image and not immediately below the tagline indicates that 
> the majority of the tagline imaging process is okay.
>
> So, where does that leave us?
>
> The options are these...
>
> 1) there still could be an error in the source TIFF image document - 
> however, this is unlikely given that you've looked at it okay and that 
> it's being further processed by the tagline imaging
>
> 2) there could be some flaw in HylaFAX's T.6 decoder or encoder as it 
> decodes and then re-encodes the data during the imaging process.  This 
> is possible, but if it were the case I think that we'd see many more 
> instances of this problem with other people
>
> 3) something could be wrong the ECM framing of the image data, but 
> again, this would seem unlikely as we aren't getting these reports 
> from elsewhere
>
> 4) the receiver could have a bug in its MMR decoder  -  I think that 
> this is the most likely bet... but it's not guaranteed by any means.
>
> I don't think that there are really any other possibilities.
>
> Next thing to do, I would recommend that you use JobControl to limit 
> your faxes to these destinations to MH and MR image data compression... no
MMR.
> So you'll want to put this into your faxq configuration file
> (/var/spool/hylafax/etc/config):
>
>    JobControlCmd:  etc/jobcontrol
>
> Then restart faxq.  And then you'll want to make a file (and mark it
> executable!)  /var/spool/hylafax/etc/jobcontrol with this in it:
>
>    #!/bin/sh
>    . etc/setup.cache
>    . bin/common-functions
>    QFILE=sendq/q$1
>    parseQfile
>    case "$number" in
>        5551212|7772323)
>            echo "ModemSoftRTFCC: no"
>            echo "DesiredDF: 0";;
>    esac
>    exit 0
>
>
> Instead of "5551212" and "7772323" put your destinations' phone numbers. 
> That will limit faxes to be MH to those destinations.  ECM will still 
> be used.  So any errors will be limited to one single scanline.
>
> Then send faxes and see how things go.
>
> 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*




____________________ 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*