2002.07.24 16:09 "Re: CCITT Group 4 assistence needed for HylaFAX", by Frank D. Cringle

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.

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