Return-Path: owner-tiff@olympiakos.com
Return-Path: <owner-tiff@olympiakos.com>
Received: from nataly.at1895.spb.edu (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.4/8.12.4/Debian-4) with ESMTP id g6OGWFxd023278
	for <dron@at1895.spb.edu>; Wed, 24 Jul 2002 20:32:15 +0400
Received: from olympiakos.com (uucp@localhost)
	by nataly.at1895.spb.edu (8.12.4/8.12.4/Debian-4) with UUCP id g6OGWFht023276
	for dron@at1895.spb.edu; Wed, 24 Jul 2002 20:32:15 +0400
Received: from knot.pu.ru (knot.pu.ru [193.124.85.214] (may be forged))
	by wg.pu.ru (8.9.1a/8.9.1) with ESMTP id QAA22120
	for <dron@at1895.spb.edu>; Wed, 24 Jul 2002 16:25:08 GMT
Received: from gate7.olympiakos.com (sdsl-64-32-199-150.dsl.iad.megapath.net [64.32.199.150])
	by knot.pu.ru (8.9.3/8.9.0) with ESMTP id UAA46018
	for <dron@at1895.spb.edu>; Wed, 24 Jul 2002 20:25:07 +0400 (MSD)
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id MAA01432;
	Wed, 24 Jul 2002 12:19:09 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Wed, 24 Jul 2002 12:09:58 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id MAA01338
	for tiff-outgoing; Wed, 24 Jul 2002 12:09:58 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from lilly.ping.de (IDENT:qmailr@lilly.ping.de [62.72.90.2])
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id MAA01335
	for <tiff@olympiakos.com>; Wed, 24 Jul 2002 12:09:57 -0400
Received: (qmail 9775 invoked by uid 10); 24 Jul 2002 16:09:52 -0000
Received: from cliwe.ping.de by lilly.ping.de with UUCP (rmail-0.2-fdc); 24 Jul 2002 16:09:52 -0000
Received: (qmail 24587 invoked by uid 500); 24 Jul 2002 16:09:40 -0000
To: tiff@olympiakos.com
Subject: Re: CCITT Group 4 assistence needed for HylaFAX
References: <20020723225031.GA3059@bilbo> <20020724103513.A11508@jcpenney.com>
From: fdc@cliwe.ping.de (Frank D. Cringle)
Date: 24 Jul 2002 18:09:40 +0200
In-Reply-To: <20020724103513.A11508@jcpenney.com>
Message-ID: <m3vg75w1iz.fsf@sabre.ping.de>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-tiff@olympiakos.com
Precedence: bulk
Status: RO
Content-Length: 3326
Lines: 66

Joel Schumacher <jschumac@jcpenney.com> writes:
> In order to do that, it seems you'd need to know the length ahead
> of time.  Or at least assume a length, like 11 inches * vertical
> resolution.
> 
> Anyone?

CCITT (er.. ITU) Rec T.5 gives a set of recommended widths.  1728
pixels is the usual for DIN A4 and 8.5x11 paper.  The number of lines
is "whatever it takes" given the resolution and paper length.

> > In HylaFAX's faxd/TagLine.c++ there is yet another large function, 
> > FaxModem::imageTagLine(), which strips a few lines from the top of the 
> > image and replaces them with created lines which image the facsimile 
> > tagline information.  It does this in accordance with Group 3 protocol 
> > (i.e., with EOLs) rather than Group 4.
> 
> I would assume you'd have to decode the entire image then re-encode it.
> Since this type of encoding is based on changes from line to line, any
> small change can affect the rest of the image.  Like somebody else said,
> a single error ruins the rest of the image.  A single bit change at the
> top will do the same.
> 
> What's more, encoding what you have to encode will, in most cases,
> encode at a different size than what was there to begin with.
> 
> Like somebody said, *IF* G4 has pad bits and you can get away with
> encoding something smaller, you might be able to put it in there

It's possible to get the encoding right but unlikely to be worth the
effort to do it incrementally, rather than using a brute-force
decode/encode.  Say you want to replace the first N scanlines with M
other lines.  You decode the first N+1 lines, encode the M new lines
followed by the N+1st old line.  You now have a 7/8 chance of being on
the wrong bit boundary to match the remains of the raw data, in which
case you would have to shift it all while moving it to some target
area or outputting it.  As you say, the size will change in general so
it needs to be copied elsewhere anyway.

> (not that it wouldn't screw up the rest of the image, but...).
> My guess is that most paper has margins and is mostly white space at
> the edge of the page.  It sounds like what your application is going
> to do is place some sort of text or header there, which by common
> sense is going to encode larger than white space.  So it's not going
> to fit in the same area you're replacing.
> 
> I'm thinking the only way to do it might be to leave the start of the
> image the same, but then prepend your raw data with your new data.
> Just be sure there is a blank white line after your data.  This may
> work because G4 assumes an imaginary white line above the first line.

Yes.  Good idea.

> It uses this as a reference and encodes line 1 based on how it differs
> from a white line.  So, if the last line of your prepended data is a
> white line, the rest of the image *should* decode properly.
> 
> The only problem with this is the length of the image.  You're now
> adding x-number of lines to it, not replacing the top x lines.
> 
> And if you want to shorten the bottom, you're back to decoding the
> raw data again to cut off the bottom.

-- 
Frank Cringle,      fdc@cliwe.ping.de
voice: (+49 7745) 928759; fax: 928761

To subscribe or unsubscribe email tiff-request@olympiakos.com with subscribe
or unsubscribe in the email body.  Libtiff home page: http://www.libtiff.org

