Return-Path: <tiff-admin@remotesensing.org>
Received: from inmx005.isp.belgacom.be (inmx005.isp.belgacom.be [195.238.3.148])
        by mailst006.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i59HPpQJ002948
        for <joris.at.lebbeke@skynet.be>; Wed, 9 Jun 2004 19:25:51 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com ([208.24.120.44])
        by inmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i59HPfCd007389
        for <joris.at.lebbeke@skynet.be>; Wed, 9 Jun 2004 19:25:41 +0200
        (envelope-from <tiff-admin@remotesensing.org>)
Received: from yoda.imagelinks.com (localhost.localdomain [127.0.0.1])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i59HOGV19148;
	Wed, 9 Jun 2004 13:24:16 -0400
Received: from pollux.zylab.nl ([213.201.159.34])
	by yoda.imagelinks.com (8.11.6/8.11.6) with ESMTP id i59HNmV19119
	for <tiff@remotesensing.org>; Wed, 9 Jun 2004 13:23:48 -0400
Received: from zyback2.zylab.nl (unknown [192.168.1.2])
	by pollux.zylab.nl (Postfix) with ESMTP id 03CFB1D94E
	for <tiff@remotesensing.org>; Wed,  9 Jun 2004 13:55:02 +0200 (CEST)
Received: from zymail.zylab.nl ([192.168.1.10]) by zyback2.zylab.nl with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 9 Jun 2004 19:21:54 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Re: [Tiff] TIFF validation
Message-ID: <44E68E8A7590D411862200508B9AFC2201AFF3F7@zymail.zylab.nl>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: TIFF validation
Thread-Index: AcROL1vHTTcJVMK2QBWgsGWRLyDwMwAEj34Q
From: "Gerben Vos" <gerben@ZyLAB.COM>
To: <tiff@remotesensing.org>
Cc: "Loygorri, Fernando" <FLoygorr@inovant.com>
X-OriginalArrivalTime: 09 Jun 2004 17:21:54.0218 (UTC) FILETIME=[426AA8A0:01C44E46]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by yoda.imagelinks.com id i59HNmV19119
Sender: tiff-admin@remotesensing.org
Errors-To: tiff-admin@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Post: <mailto:tiff@remotesensing.org>
List-Subscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
List-Id: TIFF and libtiff discussion <tiff.remotesensing.org>
List-Unsubscribe: <http://remotesensing.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://remotesensing.org/pipermail/tiff/>
Date: Wed, 9 Jun 2004 19:21:53 +0200
X-UIDL: 4ca6fd7c6e5045a207fb8788dbda251c

Loygorri, Fernando wrote:

> Page 21 of the 6.0 specification indicates that the type of
> the ImageWidth field is "SHORT or LONG". [...]

> On the other hand, page 16 of the same document says: "TIFF
> readers should accept BYTE, SHORT, or LONG values for any
> unsigned integer field." [...]

> I'm aware that "should" implies a recommendation (page 12);
> does this mean that the note on page 16 has no bearing on the
> validity of a TIFF file and it just exhorts writers of viewing
> software to try to do the best they can when faced with a
> malformed TIFF file?

I guess so. You could apply the general Internet principle "be
conservative in what you send, and liberal in what you accept" here.

Notice also that page 21 specifies requirements for Baseline TIFF.
This indicates that a TIFF with an ImageWidth of type BYTE would be
non-Baseline, but may still be valid TIFF. On the other hand, page 12
seems to imply that that only holds for features explicitly designated
"not recommended for general data interchange". Seems you've found a
vagueness in the spec.

But since you're validating, and page 12 connects only the words "is"
and "shall" with compliance (actually, the connection between the two
sentences in that paragraph is vague, too), I'd say such a field is
non-compliant, or invalid, or whatever you want to call it. :-)

Also, the recommendation on page 16 seems to be concerned more with
implementation efficiency and robustness than with file validity.

If you're writing validation software, you could add options to it to
control its strictness. Options for allowing only baseline or also one
or more extensions could be useful, too. It depends on what kind of
validation you want to perform.

					Gerben Vos.
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://remotesensing.org/mailman/listinfo/tiff
