Received: by whizzer.wpd.sgi.com (921026.SGI.NOSTRIP/911001.SGI)
	 id AA03143; Thu, 10 Jun 93 18:22:13 GMT
Received: from sgi.sgi.com by whizzer.wpd.sgi.com via SMTP (921026.SGI.NOSTRIP/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 AA03135; Thu, 10 Jun 93 11:22:10 -0700
Received: from gate.demon.co.uk by sgi.sgi.com via SMTP (920330.SGI/910110.SGI)
	for tiff-relay@whizzer.wpd.sgi.com id AA03050; Thu, 10 Jun 93 11:22:05 -0700
Received: from advent.demon.co.uk by gate.demon.co.uk id aa16335;
          10 Jun 93 19:21 BST
Date: Thu, 10 Jun 93 18:05:19 BST
From: Brian Rippon <brian@advent.demon.co.uk>
Message-Id: <9306101705.AA18043@Advent>
To: tiff@sgi.sgi.com
Subject: TIFF - T4 2D subtleties
Sender: tiff-owner@sgi.sgi.com


In implementing Group3, 2D, TIFF files, there seems to be
confusion concerning the positioning of the EOL+1 and EOL+0's
relative to byte boundaries, strips (and tiles).

TIFF6 says that fill bits, if added, are such that EOL always
ends on a byte boundary.

I think tifflib interprets the spec by ensuring that EOL+1 or
EOL+0 always ends on a byte boundary. Doesn't this contradict the
spec?

Secondly, does a strip (or tile) always commence with EOL+1?
If so, the last row in a strip does not contain an EOL, only
fill bits, so up to 10 fill bits may occur before the EOL.
Or should the 1 be at the start of the strip (except for the
first strip, which starts EOL+1)?

Any views? Or is it formally defined somewhere?

Thanks,

Brian


