2004.06.09 17:21 "Re: [Tiff] TIFF validation", by Gerben Vos

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.