Received: by whizzer.wpd.sgi.com (/911001.SGI)
	 id AA14601; Thu, 16 Dec 93 19:56:15 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (/911001.SGI)
	for /usr/people/sam/majordomo/wrapper resend -l tiff -h sgi.sgi.com -f tiff-owner -s -m "-oi -odq -om" tiff-list id AA14594; Thu, 16 Dec 93 11:56:13 -0800
Received: from alpha.Xerox.COM by sgi.sgi.com via SMTP (931110.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA21578; Thu, 16 Dec 93 11:56:12 -0800
Received: from torpor ([13.246.76.58]) by alpha.xerox.com with SMTP id <14545(1)>; Thu, 16 Dec 1993 11:55:14 PST
Received: by torpor (4.1/SMI-4.1)
	id AA00411; Thu, 16 Dec 93 14:52:26 EST
Date: 	Thu, 16 Dec 1993 11:52:26 PST
From: danis@xis.xerox.com (Ronald Danisewicz)
Message-Id: <9312161952.AA00411@torpor>
To: tiff@sgi.sgi.com
Subject: Group3 compressed tiffs with bit errors sans EOLS
Sender: tiff-owner@sgi.sgi.com

I work for Xerox Imaging Systems and we are regular
xv users. One thing that impressed us about xv 2.21 is
that it seems to be able to handle Group III compressed
tiff files that seem to have bit errors in them, yet lack EOLs.

John Bradley told me that xv uses the famous Leffler
library, which we have, but I guess we have an outdated
version, because it chokes on such files.
 
Could anyone tell us the method that the "new" Leffler
code uses to synch up to the beginning of an encoded line
after encountering an error in such files without EOLs ?

We guess that the routine keeps trying to start the line 
on next byte until it finds a starting byte that starts a
sequence whose decoded runs add up to the correct line width ?
But this seems pretty outlandish.

But if this is the case, how the heck do such files come into
existence ? Is there some really silly PC fax software out
there that just strips out EOLS from the raw compressed data stream
after demodulation and just zonks this raw data into a 
tiff file, bit errors and all. I always imagined that any reasonable
fax software would decompress the data, check for errors, and
do whatever it could to make sure the tiff file it outputs is
valid. If they don't do this, then why do they remove the EOLS ? 
This just makes it harder to synch up after errors.



